Re: [RFC] 64 bit platform improvements for string length and integer

I completely agree with Nikita. Why to rename LONG->INT STRLEN->STRSIZE in thousands places? Why not just define zend_long and zend_ulong to be 64-bit on 64-bit platforms and use them instead of int, ulint, zend_int, zend_uint, long, ulong where it's necessary. Anatol, I understood your point about catching incompatibility code at compile-time, but I'm not sure if the new features cost such huge code base changes. 1) 64-bit integers on Windows (they are already 64-bit on other systems) 2) 64-bit string length. I don't think many people are interested in that. Fortunately, the patch doesn't change the zval size, so it shouldn't make a lot of harm. However, usage of "zend_size_t" instead of "int" is a bit annoying. I would change it into the same "zend_long" or "zend_ulong". Thanks. Dmitry. On Sat, Jan 11, 2014 at 1:42 AM, Nikita Popov <nikita.ppv@gmail.com> wrote: > On Fri, Jan 10, 2014 at 3:58 PM, Anatol Belski <ab@php.net> wrote: > > > Hi, > > > > https://wiki.php.net/rfc/size_t_and_int64 > > > > The discussion time has come. The work on the feature branch continues. > > The current patch is stable enough to be discussed. > > > > What is the reason behind the renames of IS_LONG to IS_INT (and Z_LVAL to > Z_IVAL etc), as well as the renames in zpp (s -> S, etc)? Why can't we keep > the old names here? That should reduce the amount of ifndefs involved a > lot, as you'd only have to do it for the type declarations themselves, not > for every single usage. Or is the point here to intentionally provide a > maximum amount of BC breakage, so code doesn't "accidentally" continue to > run (e.g. I think that without the renames extensions could continue to run > mostly without issue on 32bit.) > > Nikita >