Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76826
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.216 as permitted sender)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
In-Reply-To: <53F7F6ED.1050609@lerdorf.com>
Date: Sat, 23 Aug 2014 03:10:07 +0100
Cc: Pierre Joye <pierre.php@gmail.com>,
 PHP internals <internals@lists.php.net>,
 Nikita Popov <nikita.ppv@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-ID: <DAA82FF1-72BD-48CE-A2EA-CF649612EBC3@ajf.me>
References: <CAF+90c_AMJ3SLyX7eDQq-gwFLOCQUfLus+qFfJgAgTzBpZpfEg@mail.gmail.com>	<D19D208D-06E9-4310-92DD-6F02C666138C@ajf.me> <CAEZPtU7yMbMSoB2imCH8NX7nCwXttpnf878vJeBK2UypJ_QxVQ@mail.gmail.com> <53F7F6ED.1050609@lerdorf.com>
To: Rasmus Lerdorf <rasmus@lerdorf.com>
Subject: Re: [PHP-DEV] [RFC] Better type names for int64 RFC
From: ajf@ajf.me (Andrea Faulds)


On 23 Aug 2014, at 03:05, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:

> The end result here is likely that in order to write a portable
> extension, extension authors will simply do:
>=20
> #ifndef IS_LONG
> # define IS_LONG IS_INT
> # define Z_STRLEN Z_STRSIZE
> # define RETURN_LONG RETURN_INT
> # define RETVAL_LONG RETVAL_INT
> # define Z_LVAL Z_IVAL
> ...
> #endif
>=20
> and not change a single macro anywhere in the actual code.

That=92s a very good point. It=92s easy to forget that many people write =
cross-version compatible extensions.

> That's certainly what I would do. And if the current naming survives =
we
> should provide a macro_compat.h file with the complete set.

Perhaps we could backport the new types, too, and make them just aliases =
on older PHP versions?

For example, zend_int would be a long in 5.5 and 5.6, but a =
64-bit-on-64-bit type on 7.

> Overall I don't think trying to make the macro names match the
> underlying types exactly is worth the hassle here. Our audience for =
this
> is extension authors. In most cases the author doesn't necessarily =
care
> about the subtle differences between calling it IS_LONG and IS_INT and =
I
> don't think it actually makes it any more clear to a C developer. =
"int"
> is not a well-defined cross-platform type anymore than a "long" is. So
> we are swapping one set of vague names for another set of vague names.
> I'd much rather see a nice clear README.TYPES or perhaps it is simply
> part of the existing README.PARAMETER_PARSING_API which defines =
exactly
> what these various macros mean.

+1 to that.

--
Andrea Faulds
http://ajf.me/