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

go to bug id or search bugs for

Bug #65362 strcmp null return missing from docs.
Submitted: 2013-07-30 23:36 UTC Modified: 2013-08-18 20:32 UTC
From: atli dot jonsson at ymail dot com Assigned:
Status: Not a bug Package: Scripting Engine problem
PHP Version: 5.5.1 OS:
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: atli dot jonsson at ymail dot com
New email:
PHP Version: OS:

 

 [2013-07-30 23:36 UTC] atli dot jonsson at ymail dot com 
Description:
------------
strcmp, strncmp, strcasecmp and strncasecmp will all return NULL when either 
string parameter is of a type that is invalid for string conversions, like Arrays, 
Objects and Resources.

However, the docs make no mention of this fact. (Aside from a comment.) As the 0 
value returned for equal strings, and NULL returned for invalid comparisons, are 
equal when compared in a non-strict manner, this can lead to unexpected behaviour.

There is a warning issued, but without clarification the above is still in no way 
obvious. 

Test script:
---------------
<?php
$arr = [];
$str = "PHP is awesome!";

if (strcmp($arr, $str) == 0) {
    echo "Equal!"; // Ends up here.
}
else {
    echo "Not equal!";
}

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2013-08-18 07:50 UTC] yohgaki@php.net
-Type: Documentation Problem +Type: Bug -Package: Documentation problem +Package: Scripting Engine problem
 [2013-08-18 07:50 UTC] yohgaki@php.net 
I changed bug type since this is in Zend/zend_builtin_functions.c.

Shouldn't it raise error for arrays? Currently, it simply returned.

/* {{{ proto int strcmp(string str1, string str2)
   Binary safe string comparison */
ZEND_FUNCTION(strcmp)
{
    char *s1, *s2;
    int s1_len, s2_len;
   
    if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "ss", &s1, &s1_len, 
&s2, &s2_len) == FAILURE) {
        return;
    }

    RETURN_LONG(zend_binary_strcmp(s1, s1_len, s2, s2_len));
}
/* }}} */
 [2013-08-18 07:54 UTC] yohgaki@php.net 
Other functions such as strlen()/strncmp()/etc return null. 
I'm not sure the best behavior, but E_NOTICE/E_WARNING for invalid parameters are 
preferred.
 [2013-08-18 20:32 UTC] johannes@php.net
-Status: Open +Status: Not a bug
 [2013-08-18 20:32 UTC] johannes@php.net 
This is common PHP behavior and documented in a note here: http://php.net/functions.internal
 [2013-08-18 22:34 UTC] atli dot jonsson at ymail dot com 
Yes, I realize this is common behaviour, and not as such a bug in PHP. 
That is why I originally categorized this as a documentation bug. 

The problem isn't PHP's behaviour, it's that the documentation on the 
functions I mentioned is misleading about the return type. There is no 
mention of the possibility of a null return, and while you may get away
with not mentioning this fact for most functions, in the case of these
particular functions, it can easily lead to unpredictable and hard to
find bugs.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Mon Oct 27 10:00:01 2025 UTC