re,
On Thu, Jan 23, 2014 at 10:13 AM, Pierre Joye <[email protected]> wrote:
> On Thu, Jan 23, 2014 at 9:42 AM, Dmitry Stogov <[email protected]> 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.
After a short chat with Dmitry, it seems that the only open questions are:
- renaming
. pros
. 100% compile time checks, unvaluable
. clarity, no magic as we have now
. code correctness, any 64bit port guides cover things the way we
implemented it
. cons
. renaming will create extra work for the next 2 years
. annoying (while I can live with it given the benefits in the long run)
- SAPIs
We have discussed many times the removal of the dead SAPIs. I think
it is time to remove them and keep only those maintained and actually
working (some sapis are not even possible to use anymore)
I think we can clear these questions during the vote phases, as options.
If anyone has an idea how to keep the advantage brought by the
renaming (compile checks, clarity, code correctness) without actually
doing the renaming in extensions, please fire it :)
Cheers,
--
Pierre
@pierrejoye | http://www.libgd.org