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

go to bug id or search bugs for

Bug #15678 isset fails for 4.1.1 and CVS version
Submitted: 2002-02-22 11:03 UTC Modified: 2002-07-07 12:58 UTC
Votes:16
Avg. Score:4.9 ± 0.3
Reproduced:16 of 16 (100.0%)
Same Version:1 (6.2%)
Same OS:1 (6.2%)
From: alberty at neptunelabs dot de Assigned:
Status: Wont fix Package: Variables related
PHP Version: 4.0CVS-2002-02-2 OS: i686-pc-linux-gnu
Private report: No CVE-ID: None
View Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem:
17 - 14 = ?
Subscribe to this entry?

 
 [2002-02-22 11:03 UTC] alberty at neptunelabs dot de 
hi,

the declaration of a second dimension in a normal array results
a strange array content.

<?php
$x['c']='foo';
$x['c']['d']='bar';
print_r($x);
?>

results:

Array
(
    [c] => boo
)

is this a normal behavior?

i think this ist completely wrong, because 'd' is not string position 1.

Also a normal condition like

<?php
$x['c']='foo';
if (isset($x['c']['y'])) echo 'yep';
else echo 'no';
?>

results true ... but it is absolutely not true

i have test it on linux with the lastest cvs tree php version.

regards,

Steve

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-02-22 11:17 UTC] alberty at neptunelabs dot de 
Andrey Hristov wrote:
>The answer to your question:
><?php
>  var_dump((int) 'y');
>?>

???

this is not the answer of the second question and also not to the first one, because

<?php
$c['c']='Hallo';
echo $c[0];
?>
results:
"Notice: Undefined offset: 0 in foo.php on line 2"
 [2002-02-22 11:41 UTC] mfischer@php.net 
Btw, this has nothing to do with current CVS. This applies to at least 4.1.0 I tested (so there's nothing broken since current stable and CVS; if it's broken, it is for a long time)
 [2002-02-23 22:59 UTC] yohgaki@php.net 
It should be fixed before 4.2.0 at least.
Hopefully before 4.1.2 :)
 [2002-02-27 07:24 UTC] derick@php.net 
not critical
 [2002-02-28 03:47 UTC] yohgaki@php.net 
This is critical bug in any cases.
isset() must not return FALSE when value is not set.  This is enough to be a critical bug.

This bug is not only hard to find, but also can make security hole in script. Don't you have script relys on isset() to grant access? (Well,  I don't have actually since I like everything to be explicit, but some users will have)
 [2002-02-28 04:29 UTC] yohgaki@php.net 
OOPS.
isset() must not return FALSE when value is not set.

should be

isset() must not return TRUE when value is not set.
 [2002-03-26 03:59 UTC] derick@php.net 
Not critical. PHP can not work around *all* user errors.

Derick
 [2002-04-19 14:43 UTC] warnke at freistunden dot de 
Hello, 

i've noticed this error to and i think it is very critical.

I think the error has to do with strings that are checked as if they were arrays.

example:

$string = 'wef23';
if(isset($string['key'])) {
	echo 'true';
} else {
	echo 'false';
}

it always returns true.

Tested with:

- PHP Version 4.1.1 (Linux infong 2.2.20-hap-2 #1 Fri Dec 14 17:08:09 CET 2001 m68k recovery) [Suse Linux]
- PHP Version 4.0.6 (OpenBSD i386.ports.openbsd.org 3.0 GENERIC#2 i386)
- PHP Version 4.1.0 (Windows NT 5.1 build 2600) [Windows XP]

You can get around this bug if you add an extra check:
if(is_array($string) && isset($string['key'])) 

but i think this could easily be done in the php c souces, or not?

bye

Lutz Warnke
 [2002-07-07 12:58 UTC] derick@php.net 
As we said before: We can not work around all user mistakes. Changing the status to "Won't fix"
 [2002-08-01 14:51 UTC] Warnke at freistunden dot de 
Hello

use the function 

key_exists() 
(PHP version 4.0.6)

or 

array_key_exists()
(PHP 4 >= 4.1.0)

this should solve all the problems


cu
Lutz Warnke
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Mon Oct 27 00:00:01 2025 UTC