On Wed, Feb 14, 2018 at 1:16 AM Pedro Lacerda <pslace...@gmail.com> wrote:
> Hi developers,
> Trying to resolve the bug #75950 (that after long hours I found that I
> couldn't reproduce), I observed that if `zend.assertions >= 0` the
> generated code inside `assert()` was indeed executed even if `assert.active
> = off`. Naturally the function arguments were evaluated before entering
> into the `assert()` function.
> The point is that will be possible to fully disable assertions setting
> `assert.active = false` after initialization if we turn `assert` into a
> statement. This can mantain fully backward compatibility. Calling
> `assert_options(ASSERT_ACTIVE, true)` or `false` after initialization would
> fully enable or disable the functionality. It seems the most sensible thing
> to do.
> By the way `assert` in Java and Python is an statement, and in C it isn't a
> So my question is what is the purpose of mantaining `assert()` a function,
> there are any drawbacks of fully disabling it when `zend.assertions >= 0`?
> PS: Strange that nobody cared in recent emails about the proposal to a
> small increase of the testing coverage by doubling the testing time
> duration, was somewhat interesting.
Assert.active is the legacy PHP 5 control. Don’t use it.
zend.assertions -1 has the behavior you want. 0 emulates PHP 5 and
earlier’s broken implementation of assert. If you don’t have legacy
software to babysit, don’t use it.