Zig Version
0.16.0
Steps to Reproduce, Observed Behavior, and Expected Behavior
When zig listens/connects to abstract unix sockets, the socklen calculation is off by one, which results in trailing 0 in the socket name. I think this issue comes from that the pathname unix sockets should be null terminated - so the function sets the byte and increases path_len. But that should not be done for abstract sockets. As per man 7 unix (note the missing null-termination in abstract sockets description)
Pathname sockets
When binding a socket to a pathname, a few rules should be observed for maximum portability and ease of coding:
• The pathname in sun_path should be null-terminated.
...
...
Abstract sockets
Socket permissions have no meaning for abstract sockets: the process umask(2) has no effect when binding an abstract socket, and changing the ownership and permissions of
the object (via fchown(2) and fchmod(2)) has no effect on the accessibility of the socket.
Abstract sockets automatically disappear when all open references to the socket are closed.
The abstract socket namespace is a nonportable Linux extension.
For example when I listen on Io.net.UnixAddress.init("\x00srv.sock") and then run ss -xl, what I expect to see is @srv.sock, what I actually see is @srv.sock@
As a result it is currently impossible to listen on or connect to abstract unix socket that doesn't end with 0. Also see https://codeberg.org/psznm/zig-playground/src/branch/abstract-socket-incompatibility-repro/src/main.zig and https://github.com/lalinsky/zio/issues/520