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 <[email protected]> wrote:
> On Fri, Jan 10, 2014 at 3:58 PM, Anatol Belski <[email protected]> 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
>