When binding server to a UNIX socket in an abstract namespace, the address length is wrong #50889
Description
Version
20.10.0
Platform
Linux debian 6.1.0-10-arm64 #1 SMP Debian 6.1.37-1 (2023-07-03) aarch64 GNU/Linux
Subsystem
No response
What steps will reproduce the bug?
new http.Server().listen("\0foo")
How often does it reproduce? Is there a required condition?
Every time
What is the expected behavior? Why is that the expected behavior?
The server binds to a socket that lsof -U renders as @foo. Other processes can connect to that socket.
What do you see instead?
The server binds to a socket that lsof -U renders as @foo@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
It looks like the address length is not set correctly.
I tried binding a C++ program to an abstract socket (using ZeroMQ) and lsof rendered that one as I'd expect (not padded), so this isn't some quirk of lsof, as far as I know.
Additional information
I don't see any reference to abstract namespaces in the documentation, so I'm not sure if this is officially supported. However, I note PR #49667, which appears to be about fixing this, and which introduces a test that binds using the same address syntax (a null byte followed by a name). AFAICT that landed in 20.8.0, so I was hoping this would work.
(That test connects to the socket using http.get, and I can do the same thing locally and it works... but the fact that lsof renders the address that way seems like there is a bug somewhere...)