php-src/Zend/tests/bug47704.phpt

--TEST--
Bug #47704 (crashes on some "bad" operations with string offsets)
--FILE--
<?php
$s = "abd";
$s[0]->a += 1;
?>
--EXPECTF--
Fatal error: Uncaught Error: Cannot use string offset as an object in %sbug47704.php:%d
Stack trace:
#0 {main}
  thrown in %sbug47704.php on line %d
Fixed bug #47704 (crashes on some "bad" operations with string offsets) Removed unnecessary checks 2009-03-18 12:52:58 +00:00			`--TEST--`
			`Bug #47704 (crashes on some "bad" operations with string offsets)`
			`--FILE--`
			`<?php`
			`$s = "abd";`
			`$s[0]->a += 1;`
			`?>`
			`--EXPECTF--`
Revert "Fetch for read in nested property assignments" This reverts commit bb43a3822e42dbd15b1d416a166549d3980b379a. After thinking about this a bit more, this is now going to be a complete solution for the "readonly properties" case, for example: unset($foo->readOnly->bar); should also be legal and $foo->readOnly['bar'] = 42; should also be legal if $foo->readOnly is not an array but an ArrayAccess object. I think it may be better to distinguish better on the BP_VAR flag level. Reverting for now. 2020-03-18 13:52:22 +00:00			`Fatal error: Uncaught Error: Cannot use string offset as an object in %sbug47704.php:%d`
Display EngineExceptions like ordinary exceptions TypeException stays as-is for now because it uses messages that are incompatible with the way exception messages are displayed. closure_038.phpt and a few others now show that we're generating too many exceptions for compound operations on undefined properties -- this needs to be fixed in a followup. 2015-05-15 19:04:07 +00:00			`Stack trace:`
			`#0 {main}`
			`thrown in %sbug47704.php on line %d`