php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Doc Bug #70600 Possible shmop_open() return values
Submitted: 2015-09-28 18:47 UTC Modified: 2015-09-29 20:38 UTC
From: root at jusme dot org Assigned:
Status: Not a bug Package: Documentation problem
PHP Version: 5.6.13 OS: Any
Private report: No CVE-ID: None
View Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem:
39 - 20 = ?
Subscribe to this entry?

 
 [2015-09-28 18:47 UTC] 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.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2015-09-28 20:45 UTC] requinix@php.net
-Status: Open +Status: Not a bug
 [2015-09-28 20:45 UTC] 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-29 15:12 UTC] 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-29 20:38 UTC] requinix@php.net 
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.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Tue Nov 04 03:00:01 2025 UTC