Re: 64-bit integers and 64-bit string length patch is ready to be merged

From: Date: Thu, 21 Aug 2014 17:42:02 +0000
Subject: Re: 64-bit integers and 64-bit string length patch is ready to be merged
References: 1  Groups: php.internals 
Request: Send a blank email to internals+get-76756@lists.php.net to get a copy of this message
On 21 Aug 2014, at 18:23, Dmitry Stogov <dmitry@zend.com> 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/

« previous php.internals (#76756) next »