-
Notifications
You must be signed in to change notification settings - Fork 7.9k
[RFC] Path to Saner Increment/Decrement operators #10358
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Alphabetic increment is very useful for generating spreadsheet column names, e.g. using PHPOffice/PhpSpreadsheet.
|
This is not the place to discuss RFCs the internal mailing list is, and this point was already brought up: https://externals.io/message/119290 |
Apologies for breaching etiquette. Followed links from the RFC announcement on phpc.social... |
69b6745
to
8eacb42
Compare
c55a0f2
to
f6c0a98
Compare
f6c0a98
to
25c0e2e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You should update type inference accordingly. PRE/POST_INC/DEC won't return IS_NULL, IS_FALSE, IS_TRUE any more. e.g. see:
php-src/Zend/Optimizer/zend_inference.c
Line 2634 in 071bf46
tmp |= MAY_BE_NULL; |
php-src/Zend/Optimizer/zend_inference.c
Line 2646 in 071bf46
tmp |= t1 & (MAY_BE_FALSE | MAY_BE_TRUE | MAY_BE_OBJECT); |
php-src/Zend/Optimizer/zend_inference.c
Line 2667 in 071bf46
tmp |= MAY_BE_NULL; |
php-src/Zend/Optimizer/zend_inference.c
Line 2708 in 071bf46
tmp |= t1 & (MAY_BE_FALSE | MAY_BE_TRUE | MAY_BE_RESOURCE | MAY_BE_ARRAY | MAY_BE_OBJECT | MAY_BE_ARRAY_OF_ANY | MAY_BE_ARRAY_OF_REF | MAY_BE_ARRAY_KEY_ANY); |
But updating it now would make the type inference incorrect, no? As the RFC doesn't change the output of these operators yet, just that they start emitting E_WARNINGs and E_DEPRECATED diagnostics. Or, because, those operations emits diagnostics the type inference bails out and thus I should already update it to not forget? |
@dstogov do I need to do anything in particular for |
25c0e2e
to
497f687
Compare
Oh, I stopped reading RFC at "Summary of behavioural differences". Then you shouldn't update inference code now. |
Sorry, I closed this unintentionally. Re-opened. |
497f687
to
a28b1f3
Compare
…ting do_operation
Yes, now there are memory leaks and bugs but this is too much black magic for me
Fix the empty string case, don't think this is the solution for non ASCII strings as I'm not sure *what* the behaviour should be
283ed45
to
12d84fe
Compare
This broke something (OSS Fuzz #60709). The following script produces incorrect output and leads to assertion in tracing JIT (PHP-8.2 works fine). <?php
set_error_handler(function($_, $m) {
echo "$m\n";
unset($GLOBALS['x']);
});
var_dump($x--);
unset($x);
var_dump($x++);
unset($x);
var_dump(--$x);
unset($x);
var_dump(++$x);
?>
|
Another problem (OSS Fuzz #60734) - use-after-free visible in ASAN build. <?php
class Foo{
}
$test = new Foo;
$y = ++$test;
?>
|
@iluuu1994 has already told me about those and I did do some work on them. Will continue this week |
There is yet another problem related to this - https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=62294 <?php
set_error_handler(function() {
unset($GLOBALS['x']);
});
$x=" ";
var_dump(--$x);
?>
|
RFC: https://wiki.php.net/rfc/saner-inc-dec-operators
The goal of this RFC is to normalize the behaviour of
$v++
and$v--
to be the same as$v += 1
and$v -= 1
, respectively.