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
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
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