On 8/22/14, 11:38 AM, Pierre Joye wrote: > On Aug 22, 2014 5:33 PM, "Andrea Faulds" <a...@ajf.me> wrote: >> >> >> On 22 Aug 2014, at 12:16, Nikita Popov <nikita....@gmail.com> wrote: >> >>> As we were not given a chance to resolve this issue before the merge, a >>> short proposal has been created, which aims to revert all unnecessary >>> naming changes and instead use type names that are consistent with the >>> existing code base and expectations: >>> >>> https://wiki.php.net/rfc/better_type_names_for_int64 >>> >>> Due to the unexpected merge on short notice, with no chance for > discussion, >>> this issue is blocking a number of other patches. As such I ask if we > can >>> move through this RFC with a shortened cycle. I would not appreciate > having >>> to wait three weeks to have a workable codebase again. >> >> I’m very much in favour of this RFC. It is not necessary to change the > type names after all; if people turn on compiler warnings, they’ll find out > what’s broken anyway. > > That's one of my points. They won't for all cases. And why good names > reflecting the underlying type will help. It is what the 1st version if the > int64 rfc did.
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 certainly what I would do. And if the current naming survives we should provide a macro_compat.h file with the complete set. 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. -Rasmus
signature.asc
Description: OpenPGP digital signature
