Doc #70600 [NEW]: Possible shmop_open() return values
| From: | root at jusme dot org | Date: | Mon, 28 Sep 2015 18:47:01 +0000 |
| Subject: | Doc #70600 [NEW]: Possible shmop_open() return values | ||
| Groups: | php.doc.bugs | ||
| Request: | Send a blank email to doc-bugs+get-12785@lists.php.net to get a copy of this message | ||
From: root at jusme dot org
Operating system: Any
PHP version: 5.6.13
Package: Documentation problem
Bug Type: Documentation Problem
Bug description:Possible shmop_open() return values
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 bug report at https://bugs.php.net/bug.php?id=70600&edit=1
--
Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=70600&r=trysnapshot54
Try a snapshot (PHP 5.5): https://bugs.php.net/fix.php?id=70600&r=trysnapshot55
Try a snapshot (trunk): https://bugs.php.net/fix.php?id=70600&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=70600&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=70600&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=70600&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=70600&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=70600&r=oldversion
Not developer issue: https://bugs.php.net/fix.php?id=70600&r=support
Expected behavior: https://bugs.php.net/fix.php?id=70600&r=notwrong
Not enough info: https://bugs.php.net/fix.php?id=70600&r=notenoughinfo
Submitted twice: https://bugs.php.net/fix.php?id=70600&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=70600&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=70600&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=70600&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=70600&r=isapi
Install GNU Sed: https://bugs.php.net/fix.php?id=70600&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=70600&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=70600&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=70600&r=mysqlcfg