Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73958
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 82.113.146.227 as permitted sender)
Date: Tue, 6 May 2014 10:13:33 +0100 (BST)
To: Anatol Belski <anatol.php@belski.net>
cc: PHP Internals <internals@lists.php.net>
In-Reply-To: <a1b3a511b2e0163fd87a6ab639c52817.squirrel@webmail.klapt.com>
Message-ID: <alpine.DEB.2.10.1405060956350.4404@whisky.home.derickrethans.nl>
References: <a1b3a511b2e0163fd87a6ab639c52817.squirrel@webmail.klapt.com>
User-Agent: Alpine 2.10 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-1948146427-1399367613=:4404"
Subject: Re: [PHP-DEV] [RFC] 64 bit platform improvements for string length
 and integer
From: derick@php.net (Derick Rethans)

--8323329-1948146427-1399367613=:4404
Content-Type: TEXT/PLAIN; charset=UTF-8
Content-Transfer-Encoding: QUOTED-PRINTABLE

On Tue, 6 May 2014, Anatol Belski wrote:

> I would sincerely invite everyone to the resurrected=20
> str_size_and_int64 RFC discussion.
>=20
> I propose the discussion to last for one week as allowed by the voting=20
> RFC because this topic has already been discussed to death previously=20
> (any objections?). As no userland change is introduced, the discussion=20
> would end and the voting would start on May 13th with 50%+1 votes=20
> requirement.
>=20
> https://wiki.php.net/rfc/size_t_and_int64_next

I see this still says "The usage of long datatype continues on 32 bit=20
platforms." =E2=80=94 do I understand correctly that on 32bit platforms, th=
ere=20
won't still be a 64bit integer in PHP and that this "only" makes 64bit=20
integers work on the Windows LLP64 model? Or are they still 32bit=20
integers there?

Under "Accepting values with zend_parse_parameters()"

=E2=80=9Cl=E2=80=9D =09=E2=80=9Ci=E2=80=9D =09to accept integer argument, t=
he internal var has to be declared as php_int_t (inside PHP) or zend_int_t =
(inside Zend)
=E2=80=9CL=E2=80=9D =09=E2=80=9CI=E2=80=9D =09to accept integer argument wi=
th range check, the internal var has to be declared as php_int_t (inside PH=
P) or zend_int_t (inside Zend)

Using l and I is going to be major confusing and incredibly hard to=20
spot.

"'l', 'L', 's', 'p' parameter formats aren't available anymore"

That means that every zpp call now needs to have an #ifdef around it to=20
support post-this-patch and pre-this-patch PHP versions, as well as=20
around their variable declarations. I'm afraid that will result in a=20
huge mess, so we should look at this again.

Under "Example on accepting parameters with zpp"

You have:
=09zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "iISP"

But why is both i and I allowed (or did I misread the Old/New before?)=20
If so, then my comment on i, l, I is already valid :-)

Under "Example on printf specs usage"

You have:
=09php_error_docref(NULL TSRMLS_CC, E_WARNING, "Value '" ZEND_INT_FMT "' is=
 out of range", i0);

Using that macro there feels really unnatural, and many C developers=20
will not bother to figure out that they use that, of course ,because=20
they are familiar with "%d" and "%l".=20

And similarly under "Example on printf specs usage (no BC)" for:

=09"Value '%pd' is out of range", i0

The new macros that you use in the example for "char *dup_substr(zval=20
*s, zval *i)" also infer that all those accesses need to have a big=20
#ifdef around stuff to support multiple versions. Again, making it a=20
major pain for extension developers to support pre- and post-patch PHP=20
versions.

I'm afraid with all those concerns, I will have to vote "no".

cheers,
Derick

--=20
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine
--8323329-1948146427-1399367613=:4404--