@[email protected] would you kindly explain why this bug has been closed without any comment? I've tried to provide every analysis I could including PHP sources. 

Doesn't that at least deserve a small token of appreciation like an answer?

Disappointed with the culture :(

It was closed because it was fixed. And there *was* a comment for that - it was automatic so sorry if you wanted something more personal.

What is your problem?

There was a bugfix commited including a changelog entry pointing to this Bugreport - so what about you are whining?

> It was closed because it was fixed. And there *was* a comment for that - it was automatic so sorry if you wanted something more personal.

Great. My mistake I didn't notice that- had expected it in the "changes" section, sorry for the confusion.

> What is your problem? There was a bugfix commited including a changelog entry pointing to this Bugreport - so what about you are whining?

I think that's the exact tone that doesn't attract people. If you read my comment you'll notice it wasn't rude...

"disappointed with the culture" when the fix was commited to 20 days after the report and within nearly 5 months you are NOT willing to read the existing comments or even update php where you would have seen it fixed and in the NEWS file *is rude*

Mhm. The bug is in the changelog for 7.1.7 but I'm still seeing it (or something similar) in 7.1.8.

It has actually gotten worse (test case from this issue):

/Users/Documents/htdocs/vz/sock.php:8:
bool(false)
/Users/Documents/htdocs/vz/sock.php:8:
string(15) "\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000"

Instead of string(1) there's now a string(15) returned.

@Harald: I'll discontinue the side discussion with you.

@rhsoft: Please stop with your tone. cpuidle simply missed a comment, which is probably caused by bugs.php.net's sub-optimal interface. It's nothing about willingness or something like that, it simply got missed.

Re-opening, as behavior got worse.

3v4l disagrees with you: https://3v4l.org/VStV6

It's still buggy on macOS, confirmed by bwoebi with yesterday's master.

Output
------

bool(false)
string(15) ""

Yep.  I just got done making a better repro and it looks like MacOS is just ever so slightly posix non-compliant here.  The spec still says any leading null byte should be considered abstract though, so I'll just check the check from len==0 to len==0 || *val=0 and should be gtg.

=============
ATTENTION!!!!
=============

THIS BUG HAS BEEN FIXED (we hope).
PLEASE REFERENCE THE ABOVE LINK TO GIT.PHP.NET FOR DETAILS ABOUT THE FIX.

=============
ATTENTION!!!!
=============

@kelunik was faster than me and @pollita ever faster at fixing.

Much appreciated, thank you :)

You're welcome, and for the record: Thank you for the detailed bug report.  It was the details which meant it was (initially) fixed in 20 days instead of 200. :)

The provided fix is incomplete / wrong. It breaks sockets using the abstract socket namespace on Linux. https://3v4l.org/RtaV2

Hrmmm.... Multiple layered things here.

How about:

    if ((ZSTR_LEN(name) == 0) ||
        ((ZSTR_LEN(name) == 1) && (ZSTR_VAL(name)[0] == 0))) {
        zend_string_release(name);
        RETURN_FALSE;
    }

That would return anything using an actual abstract socket path "\0/tmp/foo" but deal with the case where Mac returns "\0" for an unbound name,

If I got it right then macOS returned multiple NUL-bytes? So that'd not work.

No, MacOS returns a single null byte which is nonsensical according to POSIX.

> string(15) ""
>
Ugh, wait, no... you're right.  That's a whole chunk of null bytes, isn't it?

Okay, I'm less keen on masking this behavior since the standard says that a leading null byte indicates abstract namespace with the following bytes providing the abstract identifier where "null bytes have no significance", which on a strict reading says that the "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0" output reported in this original bug is a valid indicator. (Even if it's probably nonsensical.)

Yes. Until there's a better fix available, it's probably better to revert the fix for now, at least for Linux (as abstract socket namespace is Linux specific IIRC). Has this been reported to Apple? I guess it should really be fixed there?

I was just checking this and tested on my Mac and no longer see the mentioned issue. Getting:

bool(false)
bool(false)

If anyone can still see any problem with this, please create a new issue with a proper reproducer.