|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #74556 stream_socket_get_name returns \0 string instead of false
Submitted: 2017-05-08 15:32 UTC Modified: 2017-12-21 17:53 UTC
Avg. Score:3.2 ± 1.5
Reproduced:0 of 0 (0.0%)
From: cpuidle at gmx dot de Assigned: pollita (profile)
Status: Re-Opened Package: Streams related
PHP Version: 7.1.7 OS: macOS
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2017-05-08 15:32 UTC] cpuidle at gmx dot de
When using UNIX sockets, php returns string(1) ''.\\0.'' for client side socket name of a client socket instead of false. 


Internally, stream_socket_get_name ( calls php_stream_xport_get_name (

The observed \0 string seems to be a returned empty C string buffer not further checked?

Test script:

$s = stream_socket_server('unix:///tmp/demo.sock');
$c = stream_socket_client('unix:///tmp/demo.sock');

    stream_socket_get_name($s, true),
    stream_socket_get_name($c, false)

Expected result:

Actual result:
string(1) ""


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2017-05-28 15:52 UTC]
Automatic comment on behalf of pollita
Log: Bugfix #74556 stream_socket_get_name() returns empty string
 [2017-05-28 15:52 UTC]
-Status: Open +Status: Closed
 [2017-10-07 10:28 UTC] cpuidle at gmx dot de 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 :(
 [2017-10-07 10:38 UTC]
-Assigned To: +Assigned To: requinix
 [2017-10-07 10:38 UTC]
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.
 [2017-10-07 10:40 UTC]
-Assigned To: requinix +Assigned To: pollita
 [2017-10-07 10:42 UTC] spam2 at rhsoft dot net
What is your problem?

There was a bugfix commited including a changelog entry pointing to this Bugreport - so what about you are whining?
 [2017-10-07 10:49 UTC] cpuidle at gmx dot de
> 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...
 [2017-10-07 10:55 UTC] spam2 at rhsoft dot net
"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*
 [2017-10-07 12:54 UTC] cpuidle at gmx dot de
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):

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.
 [2017-10-07 13:25 UTC]
@rhsoft: Please stop with your tone. cpuidle simply missed a comment, which is probably caused by's sub-optimal interface. It's nothing about willingness or something like that, it simply got missed.
 [2017-10-07 13:26 UTC]
-Status: Closed +Status: Re-Opened
 [2017-10-07 13:26 UTC]
Re-opening, as behavior got worse.
 [2017-10-07 13:27 UTC]
-Status: Re-Opened +Status: Closed
 [2017-10-07 13:27 UTC]
3v4l disagrees with you:
 [2017-10-07 13:51 UTC]
-Status: Closed +Status: Re-Opened -Operating System: OSX +Operating System: macOS -PHP Version: 7.1.4 +PHP Version: 7.1.7
 [2017-10-07 13:51 UTC]
It's still buggy on macOS, confirmed by bwoebi with yesterday's master.


string(15) ""
 [2017-10-07 14:05 UTC]
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.
 [2017-10-07 14:15 UTC]
Automatic comment on behalf of pollita
Log: Bugfix #74556 stream_socket_get_name() returns null bytes on MacOS
 [2017-10-07 14:15 UTC]
-Status: Re-Opened +Status: Closed
 [2017-10-07 14:16 UTC]


 [2017-10-07 14:21 UTC] cpuidle at gmx dot de
@kelunik was faster than me and @pollita ever faster at fixing.

Much appreciated, thank you :)
 [2017-10-07 14:41 UTC]
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. :)
 [2017-12-18 00:12 UTC]
-Status: Closed +Status: Re-Opened
 [2017-12-18 00:12 UTC]
The provided fix is incomplete / wrong. It breaks sockets using the abstract socket namespace on Linux.
 [2017-12-19 18:02 UTC]
Hrmmm.... Multiple layered things here.

How about:

    if ((ZSTR_LEN(name) == 0) ||
        ((ZSTR_LEN(name) == 1) && (ZSTR_VAL(name)[0] == 0))) {

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,
 [2017-12-19 22:08 UTC]
If I got it right then macOS returned multiple NUL-bytes? So that'd not work.
 [2017-12-19 23:19 UTC]
No, MacOS returns a single null byte which is nonsensical according to POSIX.
 [2017-12-21 17:53 UTC]
> 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.)
 [2017-12-21 18:40 UTC]
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?
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Jun 13 07:01:34 2024 UTC