ID: 40021 User updated by: wharmby at uk dot ibm dot com Reported By: wharmby at uk dot ibm dot com Status: Wont fix Bug Type: Unknown/Other Function Operating System: Windows XP PHP Version: 4CVS-2007-01-04 (snap) Assigned To: iliaa New Comment:
Thanks for taking at look at this one Ilia. Having taken onboard your concerns regarding the performance impact of my initial patch for a function which I agree has little value outside of a testing environment could I ask you to consider the following alternative fix as without the ability to query the current setting of "callback" writing tests to verify this aspect of the API's behaviour is more difficult. New patch: http://pastebin.ca/317353 This new fix has no impact on RINIT, whilst at the same time fixing the assert_options API to perform as documented in PHP manual allowing new tests to be written to verify the assert_options API. These new tests will be dropped into CVS by my colleague if the new fix is acceptable. Previous Comments: ------------------------------------------------------------------------ [2007-01-12 15:51:48] [EMAIL PROTECTED] In this instance addition of RINIT done on every request for functionality of dubious use in a non-test environment is IMO outweighed by the performance considerations. As such I am marking this issue as won't fix. ------------------------------------------------------------------------ [2007-01-04 13:25:21] wharmby at uk dot ibm dot com Description: ------------ This issue previously raised on Internals list but no response so raising defect to track resolution of the problem. A colleague of mine is currently working on creating new test cases to improve the coverage of the PHP test cases and whilst attempting to write new tests for the assert and assert_options functions hit on a problem when attempting to query the current setting of ASSERT_CALLBACK. using the assert_options() api. With the supplied testcase the following behaviour was expected: 1) assert_options(ASSERT_CALLBACK, "new value") would return the old setting or NULL if no value set 2) assert_options(ASSERT_CALLBACK) would return the current setting or NULL if no value set In all cases however the return value is "1", or rather a bool zval of TRUE. Looking at the code this is no surprise as the code in assert.c which processes these requests unconditionally returns with RETURN_TRUE. For all other assert options other than assert_options() function returns the old value of the specified option (or FALSE on errors) as documented in the PHP manual. Further investigation uncovered that the code actually did behave in the way we expected until it was changed to accept the array(&$obj, "methodname") syntax back in July 2001 (revision 1.32 of assert.c). At this time the return was changed to be unconditionally TRUE. Unfortunately this makes writing a test case to query the current setting of the ASSERT_CALLBACK option impossible as assert_options() no longer returns any useable information for this option, i.e to code a testcase as below that sets a value and then checks its set as expected. If the code is modified as in the attached patch to instead return the zval for the current value for the ASSERT_CALLBACK option then we are able create the new testcase to verify the assert_options() api. However, I am concerned there is a good reason this was not done when the code was changed back in 2001 although at the moment I myself cannot see one. However, even with the assert_options code modified such that assert_options(ASSERT_CALLBACK) returns the current setting of the option rather than TRUE if a script issues assert_options(ASSERT_CALLBACK) BEFORE the first call to assert() then rather than getting any php.ini setting of assert_callback NULL is returned instead. This behaviour is caused by a recent change made under defect 39718 ( http://bugs.php.net/bug.php?id=39718). The problem is that the value of the global ASSERTG(cb) is not copied to ASSERTG(callback) until the first call to assert() by a request so if the script includes a query on the setting BEFORE the first call to assert() then the value returned is the default INI setting, i.e. NULL, rather than any value specified in php.ini. The issues is easily addressed by moving the code that populates ASSERTG(callback) to a new RINIT function in assert.c. The following patches address both issues raised above: assert.c: http://pastebin.ca/304563 basic-functions.c: http://pastebin.ca/304566 The patches were built against the latest snap shot build (Jan 4 2007, 0730) and the fix has been tested on both Windows and Linux using both the supplied testcase and the existing PHPT tests for assert. If the attached patch is accepted then my colleague will then drop the improved PHP testcases for assert into CVS. Andy Wharmby IBM United Kingdom Limited Reproduce code: --------------- <?php function andy() { echo "andy called\n"; } function default_callback() { echo "default_calback called\n"; } $o = assert_options(ASSERT_CALLBACK); echo "Initial setting from php.ini is \"$o\" ...it should be default_callback!!!\n"; assert(0); $o= assert_options(ASSERT_CALLBACK, "andy"); $n= assert_options(ASSERT_CALLBACK); echo "old setting is \"$o\" new setting \"$n\"\n"; assert(0); ?> and the following php.ini setting: assert.callback="default_callback" Expected result: ---------------- Initial setting from php.ini is "default_callback" ...it should be default_callback!!! default_calback called Warning: assert(): Assertion failed in C:\Eclipse-PHP\workspace\Testcases\assertbug.php on line 16 old setting is "default_callback" new setting "andy" andy called Warning: assert(): Assertion failed in C:\Eclipse-PHP\workspace\Testcases\assertbug.php on line 21 Actual result: -------------- Initial setting from php.ini is "1" ...it should be default_callback!!! default_calback called Warning: assert(): Assertion failed in C:\Eclipse-PHP\workspace\Testcases\assertbug.php on line 16 old setting is "1" new setting "1" andy called Warning: assert(): Assertion failed in C:\Eclipse-PHP\workspace\Testcases\assertbug.php on line 21 ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=40021&edit=1
