Re: [PHP-DEV] 64-bit integers and 64-bit string length patch is ready to be merged
[email protected] (Andrea Faulds)
| Newsgroups | php.internals |
|---|---|
| Message-ID | <[email protected]> |
On 21 Aug 2014, at 18:23, Dmitry Stogov <[email protected]> wrote: > The only thing that I don't like is a massive renaming described here > https://wiki.php.net/rfc/size_t_and_int64_next#semantical_macro_renamings > > IS_LONG -> IS_INT > Z_LVAL -> L_IVAL > etc > > On one hand using INT may be more consistent, on the other hand it's going > to break habits and make addition headache for merging from php-5 (I know, > phpng already made problems) I don’t like this. With the bigints patch and RFC, I want to keep IS_LONG and the word “long” to distinguish between what would be the two types of integer: * IS_LONG/long - 32-bit or 64-bit integer (machine-dependant) * IS_BIGINT/bigint - arbitrary-size integer * IS_BIGINT_OR_LONG/integer - either a long or a bigint (pseudo-type) Replacing IS_LONG with IS_INT kinda ruins my naming scheme. The intention is that “integer” and “int” are synonyms for “long or bigint”. However, if internally an int is one thing and to userland it’s another, that would be problematic. If this goes through, I’d probably make my bigints patch rename IS_INT to something new again, probably IS_SMALLINT or even back to IS_LONG. If it must be renamed, could it be something else? IS_LONGLONG perhaps? Seems stupid on the face of it, but it’s actually a C `long long` underneath, isn’t it? FWIW, I prefer Z_LLVAL to Z_IVAL. -- Andrea Faulds http://ajf.me/