Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:27151
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain googlemail.com designates 66.249.92.170 as permitted sender)
DomainKey-Status: good
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=googlemail.com;
        h=received:message-id:date:from:user-agent:mime-version:to:subject:content-type;
        b=DcYEkn4zirzqFi9kzNIg0LDWFf6dZduXqPRUecTKAJfZ3jO72rBzZUZ8CgEQLIqrGw6xLx0LRTB1rb/tXY7AJW2o7+z7QcdPUx+9oPsQqVar40ki13geXZ7oP7oS3NOkE9NJhMXTtF+17e4iGZvjvoGdHCL1SFpiqiMKEAljkXc=
Message-ID: <45897A41.5060804@googlemail.com>
Date: Wed, 20 Dec 2006 18:00:33 +0000
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: PHP internals list <internals@lists.php.net>
Content-Type: multipart/mixed;
 boundary="------------040509030108090503060709"
Subject: Query on assert_options() api
From: andy.wharmby@googlemail.com (Andy Wharmby)

--------------040509030108090503060709
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Internals
      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 extension hit on a problem when 
attempting to query the current setting of  ASSERT_CALLBACK. using the
assert_options() api.

With the following simple testcase :

<?php

  function andy()
  {
     echo "andy called\n";
  }


  $o = assert_options(ASSERT_CALLBACK, "andy");  /* SET */
  $n = assert_options(ASSERT_CALLBACK);          /* INQ */
  echo "old setting is $o\n";
  echo "new setting is $n\n";  
?>

The expected result was  that the old (if any)  and new setting of the 
callback function name would be displayed  but the actual results was

        old setting is 1
        new setting is 1

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 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 
above 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 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.Can 
anyone think
 of a good reason why returning the zval on this api is not a good idea ?

Any comments on my proposed fix appreciated.

Regards
    Andy

Andy Wharmby
IBM United Kingdom Limited

--------------040509030108090503060709
Content-Type: text/plain;
 name="assert.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="assert.txt"

--- assert.c	2006-12-03 17:30:54.000000000 +0000
+++ assert.c.new	2006-12-20 14:55:03.259056200 +0000
@@ -286,6 +286,11 @@
 		break;
 
 	case ASSERT_CALLBACK:
+		if (ASSERTG(callback) != NULL) {
+			RETVAL_ZVAL(ASSERTG(callback), 1, 0);
+		} else {
+			RETVAL_NULL();
+		}
 		if (ac == 2) {
 			if (ASSERTG(callback)) {
 				zval_ptr_dtor(&ASSERTG(callback));
@@ -293,7 +298,7 @@
 			ASSERTG(callback) = *value;
 			zval_add_ref(value);
 		}
-		RETURN_TRUE;
+		return;
 		break;
 
 	default:

--------------040509030108090503060709--