You are right for the binding part and the documentation will be changed to reflect this soon. On the other side, the rest of your bug report is not right.

The reason socket_set_option() returns NULL is because the parameter is not a socket resource if you run your example twice (because SO_REUSEADDR was not set, of course). The parameter parsing fails and NULL is returned. In a real-world situation, you always check if the resource is not NULL when you pass it as a parameter. By the way, all the socket functions return NULL if they are not passed proper parameters. In all cases, if there is an error with the function itself (and not its parameters), FALSE is returned by this function (you can look at the source to convince yourself).

As for the flawed logic well... it isn't. Socket flags have a numeric value and always had. In this example, when socket_create_listen() fails, it returns NULL, not a flag value. 

The only bug is the example, thank you for the heads up, but that's not "a lot of bugs". 

This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation better.

Also, just fyi, the reason I compare with !== 0 is because the ONLY thing that we're sure of is that, if a flag is set, it is going to be non-null and if it is not set, it is going to be 0. Will the actual result of socket_get_option be 1 or 122306 ? We don't really know.

Hi nicobn,

> The reason socket_set_option() returns NULL is because the parameter
> is not a socket resource

The docs say socket_get_option():

"Returns the value of the given option, or FALSE on errors."

If socket_get_option() is correctly returning NULL, then the docs are
wrong and inaccurate, because the docs do not describe this behavior.

> By the way, all the socket functions return NULL if they are not
> passed proper parameters.

If this is the desired behavior, the docs should reflect it
everywhere.  Anything less is inaccurate documentation.

> As for the flawed logic well... it isn't. Socket flags have a numeric
> value and always had. In this example, when socket_create_listen()
> fails, it returns NULL, not a flag value.

> Also, just fyi, the reason I compare with !== 0 is because the ONLY
> thing that we're sure of is that, if a flag is set, it is going to be
> non-null and if it is not set, it is going to be 0. Will the actual
> result of socket_get_option be 1 or 122306 ? We don't really know.

You write:

if (socket_get_option($socket, SOL_SOCKET, SO_REUSEADDR) !== 0) {

But FALSE !== 0 is true!  And socket_get_option can return FALSE on error!  (And NULL !== 0 is true!  And socket_get_option can return NULL on input errors!)

I claim the following is both functionally correct and more readable:

if (socket_get_option($socket, SOL_SOCKET, SO_REUSEADDR)) {

Thanks for fixing the docs!

-mpb

Thank you for your concern, but when a wrong parameter is passed to a function, it always return NULL as this is not really an error with the function: it is an error with the parameter parser. All the functions behave the same and, as such, I am not going to change the thousands of functions pages in the manual but I will voice your concern to the manual editor.

If you really want to go at it and make a perfect real-world test-case, you'd have to do something like:

$rval = socket_get_option($socket, SOL_SOCKET, SO_REUSEADDR);

if (!is_integer($rval)) {
    echo "There was an error with the parser or with the function" . PHP_EOL;
} else if ($rval !== 0) {
    echo "SO_REUSEADDR is set on socket !" . PHP_EOL;
}

My initial example was loose: I figured that if you have 3 error messages on the screen, you easily understand that socket_create() failed and that, as such, you should not really expect socket_get_option() to work and/or to return a meaningful result. I understand this can be misleading so I'll commit the example with error handling.

This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation better.