-
Notifications
You must be signed in to change notification settings - Fork 3.4k
Fix sendmsg()
implementation
#24187
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Fix sendmsg()
implementation
#24187
Conversation
7b3c85c
to
7cf5386
Compare
dest
would be called while undefsendmsg()
implementation
@sbc100 I completely rewrote my PR from the ground up. I added a test, changed the fix, and I updated the PR description. |
@sbc100 ci/circleci seems to break because |
76f8e4d
to
5d47a1b
Compare
In the PR description I assume you meant to write |
I wonder if the problem can instead be fixed at a higher level. It seems that Do i'm pretty sure |
We don't support AF_NETLINK sockets so just fail early here. Replaces emscripten-core#24187
I think I found a better solution which is simply not allow the AF_NETLINK socket to be created: #24364 |
We don't support AF_NETLINK sockets so just fail early here. Replaces emscripten-core#24187
We don't support `AF_NETLINK` sockets so just fail early here. Replaces #24187
One-char fix!Finally, a little more complicated.
This PR introduces a new test. This test calls
getifaddrs()
, which internally would ultimately callsetmsg()
.The problem was there: calling
getifaddrs()
makesdest
here undefined, butsock.type === {{{ cDefs.SOCK_DGRAM }}}
would betrue
.The current behaviour would skip then the assignement and
dest
would be called just after, but throw asdest
would beundefined
.My solution is to make sure to set
dest
even if thesock.type
matches. Just to be sure, after the condition, I force the sock type. Therefore, I think the intent of #22630 is respected.Fixes #23046.