|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #65792 Incomplete return values
Submitted: 2013-09-30 20:18 UTC Modified: 2013-10-01 18:22 UTC
From: chris at unix-ninja dot com Assigned:
Status: Wont fix Package: Documentation problem
PHP Version: 5.5.4 OS:
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: chris at unix-ninja dot com
New email:
PHP Version: OS:


 [2013-09-30 20:18 UTC] chris at unix-ninja dot com
From manual page:

The documentation does not specify that strcmp() returns NULL on error. This is 
important as it could be incorrectly evaluated as a successful result if using 
simple evaluation.

For completeness, the return value of NULL on error should be mentioned in the 

Test script:
@ $ans == strcmp(array(), $string);

$ans now equals a successful hit. (which is wrong, but expected behaviour)


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2013-10-01 17:26 UTC]
-Status: Open +Status: Wont fix
 [2013-10-01 17:26 UTC]
This is documented at — it's been 
previously decided not to include this on each function page.
 [2013-10-01 18:08 UTC] chris at unix-ninja dot com
Unfortunately, the documentation on that page specifically states:
"In this case it will likely return NULL but this is just a convention, and 
cannot be relied upon."

I believe it would be beneficial for the individual page to explicitly mention 
the return on failure code (as many other pages do) to be more concise. Some 
users may not have seen the Internal built-in functions page, and may have 
missed valuable information. Even if one had read that page, the page itself 
states that it remains an unreliable source of information for the return code.
 [2013-10-01 18:22 UTC]
In theory, I agree with you, but the main reason for not doing this is a lack of 
resources — nobody on the documentation team has the time to audit each function 
for this (it comes down to whether the function internally uses 
zend_parse_parameters(), which most — but not all — do), and it would be just as 
bad to blanket document this and be wrong about the functions that don't use zpp.

It sucks, but that's kind of where we're at. Sorry.
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri May 24 00:01:31 2024 UTC