Doc #70600 [Nab]: Possible shmop_open() return values

Edit report at https://bugs.php.net/bug.php?id=70600&edit=1 ID: 70600 Updated by: requinix@php.net Reported by: root at jusme dot org Summary: Possible shmop_open() return values Status: Not a bug Type: Documentation Problem Package: Documentation problem Operating System: Any PHP Version: 5.6.13 Block user comment: N Private report: N New Comment: It cannot. Best I can tell, the return value is an internal resource identifier (not to be confused with the resource type) and that will never be 0. Previous Comments: ------------------------------------------------------------------------ [2015-09-29 15:12:18] root at jusme dot org Your explanation of what's going on is perfect. However I can't glean from the source whether it's possible for shmop_open() to return 0 as a valid resource id? If so then the documentation should mention something about strict type checking against FALSE for success/failure. ------------------------------------------------------------------------ [2015-09-28 20:45:11] requinix@php.net By convention, built-in functions return null when they are passed not enough arguments or arguments of the wrong type. Documenting this on every function page would be impractical so it is mentioned in the reference section under "Internal (built-in) functions": http://php.net/manual/en/functions.internal.php (Though a convention, most functions should behave this way and any which still do not probably have a specific reason preventing them from being changed.) That aside, I just checked the source code and the documentation is correct. Barring an argument problem as stated above, the function will return false under all other error conditions: invalid flags (string not of length 1), invalid access mode (flag is not one of a/c/n/w), specifying a memory size < 1 during 'c'reation, failure to create a shared memory segment, failure to obtain information about a memory segment, or failure to attach to a memory segment. https://github.com/php/php-src/blob/0437aa2/ext/shmop/shmop.c#L145 As such I would say that you do not need to worry about checking for a null return value. ------------------------------------------------------------------------ [2015-09-28 18:47:00] root at jusme dot org Description: ------------ The documentation states that shmop_open() will return FALSE on failure, but I have discovered at least one error condition (albeit a programmer error) for which it returns NULL. Test script: --------------- var_dump(shmop_open('invalid', 'n', 0660, 1)); // Returns NULL /* The implication is that code such as this doesn't work as intended: $shmid = shmop_open('invalid', 'n', 0660, 1); if ($shmid !== false) { // Success! } elseif ($shmid === false) { // Failure! } The way things stand now a developer would really need to do: if ($shmid !== false && !is_null($shmid)) { // Success! } elseif ($shmid === false || is_null($shmid)) { // Failure! } Which is quite inelegant. Or one could do: if ($shmid) { // Success! } elseif (!$shmid) { // Failure! } But since a success returns an int, I am worried that 0 could be a valid, successful return value, which would cause issues with not using strict type checking. Expected result: ---------------- I expect shmop_open() to ONLY return false on failure so that strict type checking can be employed in case 0 is a valid return value on success. Actual result: -------------- shmop_open() can return NULL if the first parameter is not of the correct type, but I am concerned there could be other failure conditions which also return a value other than false. ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=70600&edit=1