Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65560
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain golemon.com does not designate 209.85.210.180 as permitted sender)
MIME-Version: 1.0
Sender: php@golemon.com
Date: Sat, 2 Feb 2013 05:36:00 -0800
Message-ID: <CAESVnVrUaVjQvFAGqqFm=8oGV2YXXgGFm7GT3QpaQLAoL_J_oQ@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Cc: cataphract@php.net
Content-Type: text/plain; charset=ISO-8859-1
Subject: Non-pointer params, zend_parse_parameters, and the "!" modifier
From: pollita@php.net (Sara Golemon)

Last july Gustavo (cataphract@) committed
980dc7111bc1d1e759c5b6044f6e7d203915d81f "zend_parse_parameters: allow
! for non pointers" which is awesome, but it creates a difference in
behavior between pointer and non-pointer types when used with the '!'
modifier.  So before 5.5 hits freeze, I'd like to consider modifying
it to keep it inline.

For pointer types, we have long supported:

  char *foo = "bar";
  int foo_len = 3;
  if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "s!", &foo,
&foo_len) == FAILURE) return;

Which will leave foo as "bar" if NULL is passed for the parameter.

Gustavo's diff for scalars adds '!' support (this was ignored
previously) by letting the NULL get cast to the type (e.g.
false/0/0.0) and using a second zend_bool parameter to indicate if
NULL was passed or not:

  long num = 42;
  zend_bool num_was_null;

  if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "l!", &num,
&num_was_null) == FAILURE) return;

Now if the func is called with NULL as the argument, num will still be
overwritten to 0, but we'll get the flag indicating that NULL got
passed in, and we're forced to reset it to the default value (assuming
that was our intent).

Now, I get that the implementation Gustavo went with does give more
information.  We may want to handle passing NULL differently from
explicitly passing (in this case) 42.  The reason I don't like this,
is that it's really very inconsistent with established zpp semantics.
If the (anecdotally unusual) behavior of handling NULL separately from
default value is really desired, the caller can always fallback on
accepting the zval and switching on type.

Thoughts?

-Sara