Description
This is more a question than anything. I'm building luv for Amazon Linux 2023, and when running test, the test called "pipe getsockname abstract" fails for a reason that I cannot quite understand. That is, I can see why the assertion fails, but cannot see where the failure is coming from.
For context, the test has this block of code:
if isLinux then
assert(server:bind2('\0' .. pipe_name))
local name = server:getsockname()
assert(#name == #pipe_name + 1 )
assert(name:sub(1, #pipe_name + 1) == '\0' .. pipe_name)
pipe_name = name
and this is the assertion that is failing:
assert(#name == #pipe_name + 1 )
I tried some print debugging, and found that: #name is 108 while #pipe_name is a saner 17. I asked lua to print bytes within name, and they were just what I'd expect to find but padded with zeroes to 108.
0 47 116 109 112 47 117 118 45 116 101 115 116 45 115 111 99 107 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
I don't really know why this is happening and where this is happening. Rebuilding on the same machine but for Fedora 40 runs as expected.
Upon closer inspection, I can see that getsockname() returns always exactly 108 bytes padded with zero bytes as needed (reading the relevant libuv sources confirms that this is as expected because they do memset on the buffer at the start). Longer names are truncated. I'm out of ideas where the number 108 may be coming from. Okay, I now see that sun_path has the maximum of 108 bytes, however, I was under the impression that the leading zero byte in the socket name should address precisely this, and then it doesn't explain why are shorter names being padded with zero bytes to exactly 108.
Amazon Linux 2023 ships libuv-1.47.0, and the downstream patches don't muck with the related functions in any shape or form.
Has anyone bumped into this before? Any ideas why it might be happening?