# About assert() - Thread: https://externals.io/message/101867 - Original archive: https://news-web.php.net/php.internals/101867 - Started by Pedro Lacerda on 2018-02-14T07:15:57+00:00 - Messages: 6 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #101867 — Pedro Lacerda — 2018-02-14T07:15:57+00:00 URL: https://externals.io/message/101867#101867 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. https://bugs.php.net/bug.php?id=75950 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 function. 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. -- Atenciosamente, Pedro Lacerda --- ## #101868 — Michael Morris — 2018-02-14T13:13:15+00:00 URL: https://externals.io/message/101867#101868 · In reply to: #101867 > 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. > > https://bugs.php.net/bug.php?id=75950 > > 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 > function. > > 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. --- ## #101869 — Pedro Lacerda — 2018-02-14T13:43:07+00:00 URL: https://externals.io/message/101867#101869 · In reply to: #101868 The same beharviour, but `assert` as statement also uses 1 character less. Em 14 de fev de 2018 10:13 AM, "Michael Morris" escreveu: > 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. > > https://bugs.php.net/bug.php?id=75950 > > 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 > function. > > 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. --- ## #101870 — Michael Morris — 2018-02-14T15:40:09+00:00 URL: https://externals.io/message/101867#101870 · In reply to: #101869 My earlier reply was through my phone. I've since read the bug report and saw your note where you couldn't reproduce it. Assert is a statement in PHP 7. Try this code function foo() { `debug_print_backtrace()`; return true; } assert(foo()); In PHP 7 only foo() will be in the backtrace. In PHP 5 assert will be listed as well. What you are proposing has already been done. It's also why zend.assertions has three settings: 1: on, -1: off, 0: emulate PHP 5. Unless you have code on your hands that is breaking when the -1 setting is used, the 0 setting should never be used. > The same beharviour, but `assert` as statement also uses 1 character less. > > > Em 14 de fev de 2018 10:13 AM, "Michael Morris" > escreveu: > > > > > > […] > `assert.active > > […] > would > > […] > thing > > […] > isn't a > > […] > function, > > […] > 0`? > > […] > > > 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. --- ## #101871 — Niklas Keller — 2018-02-14T16:29:32+00:00 URL: https://externals.io/message/101867#101871 · In reply to: #101870 > In PHP 7 only foo() will be in the backtrace. In PHP 5 assert will be > listed as well. > > What you are proposing has already been done. It's also why > zend.assertions has three settings: 1: on, -1: off, 0: emulate PHP 5. > Unless you have code on your hands that is breaking when the -1 setting is > used, the 0 setting should never be used. I don't think that's true. 0 can be used to dynamically switch assertions on and off, which can be useful in some applications. Regards, Niklas --- ## #101873 — Pedro Lacerda — 2018-02-14T23:13:55+00:00 URL: https://externals.io/message/101867#101873 · In reply to: #101871 2018-02-14 12:40 GMT-03:00 Michael Morris : > Assert is a statement in PHP 7. Try this code > > function foo() { > `debug_print_backtrace()`; > return true; > } > > assert(foo()); > > In PHP 7 only foo() will be in the backtrace. In PHP 5 assert will be > listed as well. > I saw all that `PHP_FUNCTION` and `ZEND_PARSE_PARAMETERS` so thought that was just a regular exposed function with compilation toggled by setting. Anyway doing it directly in the lexer would avoid the argument parsing step (and turning parentesis optional). 2018-02-14 13:29 GMT-03:00 Niklas Keller : > > I don't think that's true. 0 can be used to dynamically switch > assertions on and off, which can be useful in some applications. > This can be useful for testing frameworks which does contract programming by assertions but only in development. Atenciosamente, Pedro