#49019 [NEW]: order of operations is not valid for assignment in all cases
From: michaeldnelson dot mdn at gmail dot com Operating system: freebsd PHP version: 5.2.10 PHP Bug Type: Scripting Engine problem Bug description: order of operations is not valid for assignment in all cases Description: It appears = has a higher precedence than || in some situations which is contrary to the manual. This exception is not noted as far as I can tell. var_dump(!$test = false || !$test2 = false); is being interpreted like this var_dump(!$test = (false || !$test2 = false)); instead of like this var_dump((!$test = false) || (!$test2 = false)); If I missed something my apologies. Thanks, Michael D. Nelson Reproduce code: --- --- >From manual page: language.operators.precedence --- var_dump(!$test = false || !$test2 = false); echo "TEST\n"; var_dump($test); echo "TEST2\n"; var_dump($test2); Expected result: bool(true) TEST bool(false) TEST2 NULL Actual result: -- bool(false) TEST bool(true) TEST2 bool(false) -- Edit bug report at http://bugs.php.net/?id=49019&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49019&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49019&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49019&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49019&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49019&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49019&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49019&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49019&r=needscript Try newer version: http://bugs.php.net/fix.php?id=49019&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49019&r=support Expected behavior: http://bugs.php.net/fix.php?id=49019&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49019&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49019&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49019&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49019&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49019&r=dst IIS Stability: http://bugs.php.net/fix.php?id=49019&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49019&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49019&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49019&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49019&r=mysqlcfg
#49019 [Fbk->Opn]: order of operations is not valid for assignment in all cases
ID: 49019 User updated by: michaeldnelson dot mdn at gmail dot com Reported By: michaeldnelson dot mdn at gmail dot com -Status: Feedback +Status: Open Bug Type: Scripting Engine problem Operating System: freebsd PHP Version: 5.2.10 New Comment: Thank you for the prompt response at the risk of proving myself more obtuse: I am aware of how = and || are associated it would appear to me that if || is associated on the left and it is associated before any = then (!$test = false || !$test2 = false) should evaluate to true because the left portion of this is just (!$test = false) which evaluates to true, also (!$test = false || false) evaluates to true if you meant that the false immediately to the left was causing this result this case proves otherwise. It still appears to me that ($!test = false || $!test2 = false) evaluates to false because the leftmost = operator is getting evaluated before the ||. I apologize for taking more of your time but your terse response didn't assuage my doubts on this particular issue, perhaps if you elaborated. Thanks again. Previous Comments: [2009-07-22 20:15:52] j...@php.net = is associated on right, || is associated on left, so that's exactly what your code does.. [2009-07-22 17:10:36] michaeldnelson dot mdn at gmail dot com Description: It appears = has a higher precedence than || in some situations which is contrary to the manual. This exception is not noted as far as I can tell. var_dump(!$test = false || !$test2 = false); is being interpreted like this var_dump(!$test = (false || !$test2 = false)); instead of like this var_dump((!$test = false) || (!$test2 = false)); If I missed something my apologies. Thanks, Michael D. Nelson Reproduce code: --- --- >From manual page: language.operators.precedence --- var_dump(!$test = false || !$test2 = false); echo "TEST\n"; var_dump($test); echo "TEST2\n"; var_dump($test2); Expected result: bool(true) TEST bool(false) TEST2 NULL Actual result: -- bool(false) TEST bool(true) TEST2 bool(false) -- Edit this bug report at http://bugs.php.net/?id=49019&edit=1
#49019 [Bgs]: order of operations is not valid for assignment in all cases
ID: 49019 User updated by: michaeldnelson dot mdn at gmail dot com Reported By: michaeldnelson dot mdn at gmail dot com Status: Bogus Bug Type: Scripting Engine problem Operating System: freebsd PHP Version: 5.2.10 New Comment: I read that I assumed if (!$a = foo()) this note was in reference to the ! operators precedence where $a should be as of yet unassigned. Thank you for your time. Michael D. Nelson Previous Comments: [2009-07-22 21:25:12] j...@php.net You propably also missed the fine print: "Note: Although = has a lower precedence than most other operators, PHP will still allow expressions similar to the following: if (!$a = foo()), in which case the return value of foo() is put into $a. " So what you get is quite expected. No bug here. [2009-07-22 21:00:09] michaeldnelson dot mdn at gmail dot com Thank you for the prompt response at the risk of proving myself more obtuse: I am aware of how = and || are associated it would appear to me that if || is associated on the left and it is associated before any = then (!$test = false || !$test2 = false) should evaluate to true because the left portion of this is just (!$test = false) which evaluates to true, also (!$test = false || false) evaluates to true if you meant that the false immediately to the left was causing this result this case proves otherwise. It still appears to me that ($!test = false || $!test2 = false) evaluates to false because the leftmost = operator is getting evaluated before the ||. I apologize for taking more of your time but your terse response didn't assuage my doubts on this particular issue, perhaps if you elaborated. Thanks again.) [2009-07-22 20:15:52] j...@php.net = is associated on right, || is associated on left, so that's exactly what your code does.. [2009-07-22 17:10:36] michaeldnelson dot mdn at gmail dot com Description: It appears = has a higher precedence than || in some situations which is contrary to the manual. This exception is not noted as far as I can tell. var_dump(!$test = false || !$test2 = false); is being interpreted like this var_dump(!$test = (false || !$test2 = false)); instead of like this var_dump((!$test = false) || (!$test2 = false)); If I missed something my apologies. Thanks, Michael D. Nelson Reproduce code: --- --- >From manual page: language.operators.precedence --- var_dump(!$test = false || !$test2 = false); echo "TEST\n"; var_dump($test); echo "TEST2\n"; var_dump($test2); Expected result: bool(true) TEST bool(false) TEST2 NULL Actual result: -- bool(false) TEST bool(true) TEST2 bool(false) -- Edit this bug report at http://bugs.php.net/?id=49019&edit=1
#46600 [Com]: "_empty_" key in objects (see #41504)
ID: 46600
Comment by: michaeldnelson dot mdn at gmail dot com
Reported By: Matt at mpcm dot com
Status: No Feedback
Bug Type: JSON related
Operating System: *
PHP Version: 5CVS, 6CVS (2008-11-18)
New Comment:
I am using freebsd 7.2 and php 5.2.10 the first test case
var_dump(json_decode('{"":"test"}'));
silently stops processing of the script
The test case
var_dump(json_decode('{"test2":5,"":6}'));
Fatal error: Cannot access empty property
I am not sure the second is expected behavior but considering json is
often from feeds it would be nice to fail more gracefully.
Previous Comments:
[2008-12-26 01:00:01] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2008-12-23 16:47:05] matt at mpcm dot com
A note about this in the json_decode page would be appreciated. Perhaps
a strict mode flag, so that it can fail if it cannot be decoded as an
object (?). For the moment the only safe way to decode json is into
arrays.
The _empty_ behavior I thought was a bug (as it was with arrays) is a
required behavior for objects (at least without __get && __set in a
wrapper class).
The bugs that jump out at me now can be seen with the code below... you
can create objects with unreachable properties. If that blank property
access is fixed, then this becomes not so much of an issue. Or it should
be stopped from ever happening... silent errors bite us all.
Illegal Member variable name if var_dump does it, fatal if a user does
it.
Notice: PHPDocument1 line 8 - Illegal member variable name
1234, 'some other key'=>5678, $another=>);
$b = (object) $a;
$c = json_decode(json_encode($a));
var_dump($b);
var_dump($c);
#echo $b->$blank; //fatal
echo $b->$another; //works
#echo $c->$blank; //fatal
echo $c->$another; //works
?>
[2008-12-18 03:27:25] scott...@php.net
I'm not even sure what the bug is? You can't have an empty property
name hence the use of "_empty_".
The key collision thing is a very edge case, are you saying you ran
into this in a real life usage?
The best course of action may be to have this documented on the
json_encode() and json_decode() pages.
[2008-12-04 20:39:13] Matt at mpcm dot com
Thanx for the reply magicaltux, `Feature` is an interesting word
considering the possible key collision.
There are other ways to get things that are not strictly objects to
behave that way. Overloading (like example #1 at
http://us.php.net/manual/en/language.oop5.overloading.php). It works
well enough as long as you also make it iterate correctly.
What I am suggesting is that it is better to fail in decoding into an
object, than to silently cause a key collision.
Or alternatively, produce an overloaded object which can have these
keys (by default, or passed optional flag) from json_decode. It's an
opinion, but a wrapper gets me where I need to be for now, and I'm
pretty sure this is an edge case.
$a = '{"":"a","_empty_":"b"}';
echo json_encode(json_decode($a));
echo json_encode(json_decode($a, true));
output:
{"_empty_":"b"}
{"":"a","_empty_":"b"}
for some values:
$a != json_encode(json_decode($a));
[2008-12-04 10:44:29] magical...@php.net
I believe this is not a bug, but a feature.
An object *can't* have an empty property (while an array can).
If you want to use json_decode() with json containing empty key, either
access those empty key using special keyword "_empty_", or put the
optionnal $assoc parameter of json_decode() to true to get result as an
array.
If you want objects to support empty keys, I believe this is not going
to happen soon, as this is enforced by a specific error message.
Fatal error: Cannot access empty property in php shell code on line 1
Please note that a property name starting with NULL character won't
work either.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/46600
--
Edit this bug report at http://bugs.php.net/?id=46600&edit=1
