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: Documentation Problem Package: Scripting Engine problem Operating System: FreeBSD 10.1 PHP Version: 7.0.14 Assigned To: cmb Block user comment: N Private report: N New Comment: > assert() with non-string expressions was not available prior to > PHP 7.0, […] assert() with general expressions has been available as of PHP 4.3 at least, see <https://3v4l.org/8f8gd>. > Is there any chance that this be actually fixed, rather than > updating the documentation? As for me, this is a documention issue only, but others may think otherwise about this, so I suggest you write to internals@lists.php.net. Previous Comments: ------------------------------------------------------------------------ [2017-01-13 14:41:42] vedad at kajtaz dot net Hi cmb, I somehow disagree with the backward-compatibility argument. assert() with non-string expressions was not available prior to PHP 7.0, hence IMHO bc does not apply here. And if it did, I would expect expressions of any kind not to be evaluated, after all they were not in PHP < 7. Is there any chance that this be actually fixed, rather than updating the documentation? Thanks, Kind regards ------------------------------------------------------------------------ [2017-01-12 00:00:10] cmb@php.net > 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> ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ 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