On Thu, Jan 23, 2014 at 9:42 AM, Dmitry Stogov <dmitry@zend.com> wrote:
> 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.
To catch 64bit issues at compile is immensely valuable. We had so many
issues in the past, some of them leading to security issues. It is
also a one time job, with a little extra effort for two years.
Besides the portability improvements, code review and correctness is
one of the goal of this RFC. I can't remember to know any widely known
and sane project relying on on other type for buffer length. PHP does
not have to be different :)
> 1) 64-bit integers on Windows (they are already 64-bit on other systems)
Almost all :)
> 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".
It is not about being interested but preventing many security issues
as well, by default. The large buffer availability is a good side
effect. The implementation correctness is also drastically improved in
this case.
Cheers,
--
Pierre
@pierrejoye | http://www.libgd.org