Co-authored-by: Gina Peter Banyard <girgias@php.net>
Co-authored-by: Arnaud Le Blanc <arnaud.lb@gmail.com>
Co-authored-by: Tim Düsterhus <tim@tideways-gmbh.com>
* zend_compile: Allow `(void)` in for’s initializer and loop expression
The initializer and loop expression of a `for()` loop only accept expressions,
but they act like statements in spirit - their results are completely ignored.
Allow `(void)` there to allow suppressing `#[\NoDiscard]`, since there is no
semantic ambiguity of what `(void)` returns anyways.
Fixesphp/php-src#18301
* zend_language_parser: Simplify `for()` grammar
The motivation for this is that types should be considered immutable.
The only times this is not valid is during compilation, optimizations (opcache), or destruction.
Therefore the "normal" type foreach macros are marked to take const arguments and we add mutable version that say so in the name.
Thus add various const qualifiers to communicate intent.
https://wiki.php.net/rfc/static-aviz
Optimally, this would be moved to zend_fetch_static_property_address(). However,
this isn't currently effective for opcache, because R and RW/W/UNSET cache slots
are merged. This will circumvent the visibility check if the cache is primed by
a R instruction.
Closes GH-16486
The check for `!fbc || (fbc->common.fn_flags & ZEND_ACC_VARIADIC)` is
performed after `fbc` is set to NULL, so this always returns true.
This results in `ZEND_FCALL_MAY_HAVE_EXTRA_NAMED_PARAMS` always being
set for unpack sends. Fix it by moving the flag updates to the point
before setting `fbc` to NULL.
Closes GH-17534.
Given that the `ZEND_AST_OP_ARRAY` type already needed special handling in
various places, it makes sense to give it its own struct to avoid some of the
casts. As a side benefit, it is a little smaller than the `zend_ast_zval`
struct.
* zend_compile: Do not traverse children of ZEND_AST_CLOSURE in zend_compile_const_expr()
* Add assertions verifying that zend_ast_decl AST nodes are not treated as regular zend_ast nodes
The current code expects the property name to be a string, but it can
also be a number via the {} syntax. Handle this consistently to a string
by using zval_get_string which will do the type coercion and refcount
update (instead of assuming string and doing an explicit string copy).
Closes GH-17236.
Only on Windows `IS_SLASH_P()` may read the previous byte, and so may
in unlikely cases read one byte out of bounds. Since `IS_SLASH_P()` is
in a public header (albeit not likely to be used by external extensions
or SAPIs), we introduce `IS_SLASH_P_EX()` which accepts a second
argument to prevent that OOB read.
It should be noted that the PHP userland function `dirname()` is not
affected by this issue, since it does not call `zend_dirname()` on
Windows.
Closes GH-16995.
Reproducer: https://github.com/php/php-src/issues/16727#issuecomment-2466256317
The root cause is a data race between two different threads:
1) We allocate a lower cased name for an anonymous class here:
f97353f228/Zend/zend_compile.c (L8109)
2) This gets looked up as an interned string here:
f97353f228/Zend/zend_compile.c (L8112)
Assuming that there are uppercase symbols in the string and therefore
`lcname != name` and that `lcname` is not yet in the interned string table,
the pointer value of `lcname` won't change.
3) Here we add the string into the interned string table:
f97353f228/Zend/zend_compile.c (L8223)
However, in the meantime another thread could've added the string into the interned string table.
This means that the following code will run, indirectly called via the `LITERAL_STR` macro,
freeing `lcname`: 62e53e6f49/ext/opcache/ZendAccelerator.c (L572-L575)
4) In the reproducer we then access the freed `lcname` string here:
f97353f228/Zend/zend_compile.c (L8229)
This is solved in my patch by retrieving the interned string pointer
and putting it in `lcname`.
Closes GH-16748.
This list was initially introduced in 53a40386, but never included array or
callable. I suppose this is because int & friends are not actual tokens,
while array and callable are. This means it was never possible to do class
array, which is probably the reason this was overlooked.
Closes GH-16683.
`num_args > 0` implies that `arg_info != NULL`. We explicitly assert
that during compilation and execution to make it easier for developers
to not miss this[1].
[1] <https://github.com/php/php-src/issues/16266>
For classes that are not declared `abstract`, produce a compiler error for any
`abstract` methods. For anonymous classes, since they cannot be made abstract,
the error message is slightly different.
Co-authored-by: Ilija Tovilo <ilija.tovilo@me.com>
