From: Ashley Sheridan on 8 Apr 2010 18:39 On Thu, 2010-04-08 at 15:22 -0500, Shawn McKenzie wrote: > Shawn McKenzie wrote: > > Bob McConnell wrote: > >> In the first case, $a=5 creates a multi-typed variable. The interpreter > >> makes its best guess how the next two expressions should be interpreted. > >> In both cases, they look a lot like an index into a character array > >> (string), and 'test' evaluates numerically to zero. Both are valid > >> offsets for a string, so no messages are generated. > >> > >> In the second case, $a is explicitly declared as an array. This give the > >> interpreter a lot more detail to work from. The two expressions are now > >> an index and a key for the array. But both of them evaluate to offsets > >> that have not been assigned, which raises a flag and creates the > >> warnings. > >> > >> Such are the joys of loosely typed languages. > >> > >> Bob McConnell > > > > Yes, this is what I was thinking as well, however: > > > > $a=5; > > print $a[0]; // if it is index 0 then it should print 5 yes? > > print $a[100]; // there is no index 100 so why no notice? > > > > $a='5'; > print $a[0]; // prints 5 > print $a[100]; // Notice: Uninitialized string offset: 100 > > So it seems, in the first case with the integer 5 that the interpreter > is saying: > > - Since $a is not an array I'll treat $a[0] and $a[100] as a string > offset, but since $a is not a string I won't do anything. > > Just seems stupid IMHO. > > -- > Thanks! > -Shawn > http://www.spidean.com > I think it just returns null if the offset goes beyond the length of the string. In C and C++ doing something like this would take you beyond that variables memory allocation into neighbouring variables. I believe PHP is trying to prevent problems where that might occur by returning null instead. This is only conjecture as I don't know exactly what happens, and I can't find anything in the manual that explains what should happen when you treat a string like an array in PHP. However, throwing some sort of error or notice would be nice, but could be worked around by checking the array type and length (the count() function returns the string length I believe as well as the array size) as it does seem that PHP is treating a string like a special sort of array. Thanks, Ash http://www.ashleysheridan.co.uk
From: kranthi on 8 Apr 2010 22:22 >> print $a[0]; // prints 5 >> print $a[100]; // Notice: Uninitialized string offset: 100 Yup, this should happen when 5 is treated as an array of characters. In other words as a string. $a = '5'; echo $a[0]; echo $a[100]; gives you the expected result regarding the original question, i think that the interpreter is prefilling the variable with null $a = 5; var_dump(isset($a[0])); var_dump($a[0]); since $a[0] is already assigned (to null) the interpreter is not throwing a notice $b = null; var_dump(isset($b)); var_dump($b);
From: shiplu on 8 Apr 2010 23:28 Hello Shawn, Why dont you report a bug? When we know the expected behavior or the way it SHOULD behave. and its not behaving that way. Its certainly a bug.. Only then we can know the real reason why the novicas are not showing up. On 4/8/10, Shawn McKenzie <nospam(a)mckenzies.net> wrote: > So the first two print statements generate NO notices, while the second > obviously generates: > > Notice: Undefined offset: 1 in /home/shawn/www/test.php on line 11 > > Notice: Undefined index: test in /home/shawn/www/test.php on line 12 > > This sucks. A bug??? > > error_reporting(E_ALL); > ini_set('display_errors', '1'); > > > $a = 5; > print $a[1]; > print $a['test']; > > $a = array(); > print $a[1]; > print $a['test']; > > -- > Thanks! > -Shawn > http://www.spidean.com > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Sent from my mobile device Shiplu Mokaddim My talks, http://talk.cmyweb.net Follow me, http://twitter.com/shiplu SUST Programmers, http://groups.google.com/group/p2psust Innovation distinguishes bet ... ... (ask Steve Jobs the rest)
From: Ashley Sheridan on 9 Apr 2010 05:08 On Fri, 2010-04-09 at 07:52 +0530, kranthi wrote: > >> print $a[0]; // prints 5 > >> print $a[100]; // Notice: Uninitialized string offset: 100 > Yup, this should happen when 5 is treated as an array of characters. > In other words as a string. > $a = '5'; > echo $a[0]; > echo $a[100]; > gives you the expected result > > regarding the original question, i think that the interpreter is > prefilling the variable with null > > $a = 5; > var_dump(isset($a[0])); > var_dump($a[0]); > > since $a[0] is already assigned (to null) the interpreter is not > throwing a notice > > $b = null; > var_dump(isset($b)); > var_dump($b); > If $a is treated as an array of characters, then $a[0] is always the first character, not null. Thanks, Ash http://www.ashleysheridan.co.uk
From: "Bob McConnell" on 9 Apr 2010 08:15 From: Shawn McKenzie > Bob McConnell wrote: >> In the first case, $a=5 creates a multi-typed variable. The interpreter >> makes its best guess how the next two expressions should be interpreted. >> In both cases, they look a lot like an index into a character array >> (string), and 'test' evaluates numerically to zero. Both are valid >> offsets for a string, so no messages are generated. >> >> In the second case, $a is explicitly declared as an array. This give the >> interpreter a lot more detail to work from. The two expressions are now >> an index and a key for the array. But both of them evaluate to offsets >> that have not been assigned, which raises a flag and creates the >> warnings. >> >> Such are the joys of loosely typed languages. > > Yes, this is what I was thinking as well, however: > > $a=5; > print $a[0]; // if it is index 0 then it should print 5 yes? > print $a[100]; // there is no index 100 so why no notice? I'm assuming that the PHP interpreter works much like a C compiler. i.e. It doesn't keep track of the size of strings. It knows that $a maps to a memory location, and $a[100] maps to that location plus 100 characters. As long as that is still a valid memory address for this process, it doesn't see anything wrong. If it is outside the process memory, you are more likely to get a General Protection Fault, or the equivalent OS error. In security parlance, this is what is known as a buffer overflow error. The application programmer is responsible for keeping track of string sizes and insuring that indexes don't move past the end of the allocated space. It is also why functions like snprintf should be used instead of sprintf. Bob McConnell
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 Prev: Beginner's question: How to run a PHP web application locally? Next: Forgot what to install |