On 23 Aug 2014, at 03:05, Rasmus Lerdorf <ras...@lerdorf.com> wrote:
> The end result here is likely that in order to write a portable > extension, extension authors will simply do: > > #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 > > and not change a single macro anywhere in the actual code. That’s a very good point. It’s 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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
