Fix of incorrect message size in functions getpeername, getsockname

[Denzeli]

No description provided.

[welcome]

Thank you for submitting a pull request! If this is your first PR, make sure to add yourself to AUTHORS.

[stale]

This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 30 days. Feel free to re-open at any time if this issue is still relevant.

[pjaggi1]

If you can please merge at some point that would be good-annoying bug if you happen to use the POSIX Sockets proxy server.

[juj]

Sorry, this fell completely through the cracks..

Looking at the code, I don't think the change is correct? The sockaddr field is varying in length, so its actual size is dynamically defined.

It looks to me like the code would change the sockaddr size to be zero, as sizeof(d) does not include the size of the sockaddr, just the header.

If this change is panning out for some use, I wonder if it would be due to masking some other bug?

Now while looking at this, I see that at least on Unix implementations of POSIX, hthere should exist a type sockaddr_storage that would be large enough to store any type of address (IPv4 or IPv6). https://man7.org/linux/man-pages/man3/sockaddr.3type.html Maybe that would be better to use here.

[pjaggi1]

I am a little confused-it seems like this change affects the call from the web assembly to the websocket_to_posix_proxy. Without this PR the proxy would error out because it was getting a negative packet size. With this fix the proxy unpacks the header and makes the posix getsockname call, for which it allocates its own address buffer (

emscripten/tools/websocket_to_posix_proxy/src/websocket_to_posix_proxy.c

Line 1027 in 1becb5a

uint8_t address[MAX_SOCKADDR_SIZE];

). Is this not correct?

i am not sure about the data coming back, it looks like there might not be enough allocation for the return buffer? but out to the proxy this seems ok.