Bug->Doc #73875 [Ver]: assert() evaluated despite runtime assert_options(ASSERT_ACTIVE, 0);

Edit report at https://bugs.php.net/bug.php?id=73875&edit=1 ID: 73875 Updated by: cmb@php.net Reported by: vedad at kajtaz dot net Summary: assert() evaluated despite runtime assert_options(ASSERT_ACTIVE, 0); Status: Verified -Type: Bug +Type: Documentation Problem Package: Scripting Engine problem Operating System: FreeBSD 10.1 PHP Version: 7.0.14 -Assigned To: +Assigned To: cmb Block user comment: N Private report: N New Comment: > Indeed, my result seems to have been due to the 'uopz' > extension. Disabling uopz produces the correct result. I guess I > now need to file a bug for uopz. That appears to be in order. :-) > The point is that both the "assert.active" ini setting > documentation, and the assert_options() documentation explicitly > state that they "enable" (or, implicitly, disable) evaluation. I > believe this makes more sense than the subtle string/non-string > discrepancy […] PHP 5 has only security support now[1], and the new zend.assertions setting has been explicitly designed for full backward compatibility[2], so I'm changing to doc bug. [1] <http://php.net/supported-versions.php> [2] <https://wiki.php.net/rfc/expectations#unaffected_php_functionality> Previous Comments: ------------------------------------------------------------------------ [2017-01-06 23:42:03] vedad at kajtaz dot net >> Actually, setting zend.assertions to 0 produces the same effect >> - expression in assert is still evaluated. > That would be a bug, but I can't reproduce this, see > <https://3v4l.org/EYrTO>. Please double-check. Indeed, my result seems to have been due to the 'uopz' extension. Disabling uopz produces the correct result. I guess I now need to file a bug for uopz. > Actually, assert.active=0 is not supposed to suppress the > evaluation of the assertion parameter (unless it's a string), but > rather to ignore the result of the evalutation. This works as > expected as long as the assertion expression doesn't have any > side-effects (and usually you don't want side-effects in > assertions, anyway). The point is that both the "assert.active" ini setting documentation, and the assert_options() documentation explicitly state that they "enable" (or, implicitly, disable) evaluation. I believe this makes more sense than the subtle string/non-string discrepancy (though you're right that assertions are not meant to have side effects). ------------------------------------------------------------------------ [2017-01-06 22:56:22] cmb@php.net > Actually, setting zend.assertions to 0 produces the same effect > - expression in assert is still evaluated. That would be a bug, but I can't reproduce this, see <https://3v4l.org/EYrTO>. Please double-check. Otherwise there may be the need to improve the documentation. Actually, assert.active=0 is not supposed to suppress the evaluation of the assertion parameter (unless it's a string), but rather to ignore the result of the evalutation. This works as expected as long as the assertion expression doesn't have any side-effects (and usually you don't want side-effects in assertions, anyway). > assertion() can now be an expression. Indeed, this changelog info is wrong. An expression was also allowed in former versions, but it was always evaluated, as there has been no zend.assertions (think of the PHP 5 behavior being like zend.assertions=1). ------------------------------------------------------------------------ [2017-01-06 14:32:34] vedad at kajtaz dot net Expressions are allowed in assertions since PHP 7.0: > 7.0.0 assert() is now a language construct and not a function. assertion() can now be an > expression. That being said, it is either undocumented or plain wrong that the expression be evaluated despite asserts being disabled. ------------------------------------------------------------------------ [2017-01-06 14:17:04] fernando at null-life dot com > assert($assert = true); Shouldn't this line be > assert('$assert = true'); After changing it I get the expected result: PHP VERSION 7.0.13 running cli sapi. Initial settings: zend.assertions: 1 assert.active: 1 After altering settings: zend.assertions: 1 assert.active: 0 Code in assert() was NOT evaluated ------------------------------------------------------------------------ [2017-01-06 13:28:54] vedad at kajtaz dot net Actually, setting zend.assertions to 0 produces the same effect - expression in assert is still evaluated. echo 'PHP VERSION '.PHP_VERSION.' running '.PHP_SAPI.' sapi.'.PHP_EOL; echo 'Initial settings:'.PHP_EOL; echo 'zend.assertions: '.ini_get('zend.assertions').PHP_EOL; echo 'assert.active: '.ini_get('assert.active').PHP_EOL; ini_set('zend.assertions', '0'); assert_options(ASSERT_ACTIVE, 0); echo 'After altering settings:'.PHP_EOL; echo 'zend.assertions: '.ini_get('zend.assertions').PHP_EOL; echo 'assert.active: '.ini_get('assert.active').PHP_EOL; $assert = false; assert($assert = true); if($assert) echo 'Code in assert() was evaluated'.PHP_EOL; else echo 'Code in assert() was NOT evaluated'.PHP_EOL; ------------------------------------------------------------------------ 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 https://bugs.php.net/bug.php?id=73875 -- Edit this bug report at https://bugs.php.net/bug.php?id=73875&edit=1