php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #31098 isset false positive
Submitted: 2004-12-15 17:27 UTC Modified: 2005-01-12 10:28 UTC
Votes:28
Avg. Score:4.8 ± 0.8
Reproduced:23 of 26 (88.5%)
Same Version:20 (87.0%)
Same OS:7 (30.4%)
From: jyounger at caedic dot com Assigned: dmitry (profile)
Status: Closed Package: Scripting Engine problem
PHP Version: 5CVS-2005-01-10 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: jyounger at caedic dot com
New email:
PHP Version: OS:

 

 [2004-12-15 17:27 UTC] jyounger at caedic dot com
Description:
------------
isset() when run using mod_php returns a false positive when checking a string variable for the presence of a property. isset() when run under the cli behaves correctly and returns false. This is in PHP 5.0.3RC2.

Reproduce code:
---------------
<?php
$simpleString = "Bogus String Text";

if (isset($simpleString->nonExistentStringProperty)) {
   echo "This line should not execute";
} else {
   echo "This line should execute";
}
?>

Expected result:
----------------
This line should execute

Actual result:
--------------
This line should not execute

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2004-12-17 22:19 UTC] ptchristendom at yahoo dot com
Empty() has the same problem.

<?php
$simpleString = "Bogus String Text";
var_dump(empty($simpleString->nonExistentStringProperty));
?>
 [2004-12-20 02:10 UTC] jkkn at jkkn dot dk
At time patching for bug #2 9883, 'dmitry'not only applied the patch, but also added autocasting for the offset, therefore:
isset($simpleString['nonExistentStringProperty']) is currenly autocasted into isset($simpleString[0]) - which is true.

Same goes for empty() since this is the same function.

This patch should resolve this problem:
Index: ZendEngine2/zend_execute.c
===================================================================
RCS file: /repository/ZendEngine2/zend_execute.c,v
retrieving revision 1.652.2.11
diff -u -r1.652.2.11 zend_execute.c
--- ZendEngine2/zend_execute.c	1 Dec 2004 14:01:58 -0000	1.652.2.11
+++ ZendEngine2/zend_execute.c	20 Dec 2004 01:08:28 -0000
@@ -4033,26 +4033,20 @@
 				result = Z_OBJ_HT_P(*container)->has_dimension(*container, offset, (opline->extended_value == ZEND_ISEMPTY) TSRMLS_CC);
 			}
 		} else if ((*container)->type == IS_STRING) { /* string offsets */
-			zval tmp_offset;
-
-			if (Z_TYPE_P(offset) != IS_LONG) {
-				tmp_offset = *offset;
-				zval_copy_ctor(&tmp_offset);
-				convert_to_long(&tmp_offset);
-				offset = &tmp_offset;
-			}
-			switch (opline->extended_value) {
-				case ZEND_ISSET:
-					if (offset->value.lval >= 0 && offset->value.lval < Z_STRLEN_PP(container)) {
-						result = 1;
-					}
-					break;
-				case ZEND_ISEMPTY:
-					if (offset->value.lval >= 0 && offset->value.lval < Z_STRLEN_PP(container) && Z_STRVAL_PP(container)[offset->value.lval] != '0') {
-						result = 1;
-					}
-					break;
-			}
+			if (Z_TYPE_P(offset) == IS_LONG) {
+    			switch (opline->extended_value) {
+    				case ZEND_ISSET:
+    					if (offset->value.lval >= 0 && offset->value.lval < Z_STRLEN_PP(container)) {
+    						result = 1;
+    					}
+    					break;
+    				case ZEND_ISEMPTY:
+    					if (offset->value.lval >= 0 && offset->value.lval < Z_STRLEN_PP(container) && Z_STRVAL_PP(container)[offset->value.lval] != '0') {
+    						result = 1;
+    					}
+    					break;
+	    		}
+            }
 		}
 	}
 	


Besides this the files "zend_vm_execute.h" and "zend_vm_execute.h" seem to have been messed up in CVS HEAD at the same commit?!.
 [2004-12-31 18:58 UTC] mnorth at ucsd dot edu
This bug is rather significant to anyone that uses PEAR::DB with DB_DataObject.  It effectively breaks the createTables.php script, which in turn effectively makes useless DB_DataObject.  The offending code is the first line of function tableInfo in (phproot)/lib/php/DB/mysql.php:

     * @see DB_common::tableInfo()
     */
    function tableInfo($result, $mode = null) {
        if (isset($result->result)) {
            /*
             * Probably received a result object.


The isset() call returns true, regardless of whether $result->result is set, and even if $result is not an object.  Note, this affects ALL (phproot)/lib/php/DB/??sql.php files, since they all contain tableInfo() functions.

The patch supplied in this bug report doesn't solve the problem, so I had to temporarily change function tableInfo() to call is_object() instead of isset().

Matthew H. North
 [2005-01-03 03:51 UTC] jkkn at jkkn dot dk
I am using PEAR::DB which was the main reason I wrote the patch. The supplied patch should solve all problems with regards to PEAR::DB.

Matthew, what do you experience while using the patch?
 [2005-01-10 15:27 UTC] sniper@php.net
Dmitry breaks, Dmitry fixes. :)

 [2005-01-11 23:05 UTC] moriyoshi@php.net
This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.


 [2005-01-12 10:28 UTC] dmitry@php.net
The patch for HEAD is incorrect.

You must not edit zend_vm_execute.h directly. You must edit zend_vm_def.h and then generate zend_vm_execute.h with zend_vm_gen.php. See README.ZEND_VM for more details.

I fixed this.

Also isset($str['str']) returned true, that is wrong from my point of view.

I modified the patch to return false and notification in zend_fetch_dimension_address().


 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Dec 05 16:01:30 2024 UTC