Hi,

On Wed, July 10, 2013 07:51, Pierre Joye wrote:
>> Substr needs to be refactored to use size_t. Right now, I just raise an
>>  error if Z_STRSIZE > INT_MAX (or an overflow would happen). I'd love
>> to see that cleaned up more.
>
> We should consider moving to int64_t too as well while being at it.
> For many reasons or platforms it makes sense to drop (unsigned)
> long/int usage as well (and all derived types) and uses (u)int*_t instead.
> I'd to see this task as strongly related to the size_t move.
> It will also solve many other related issues (LFS support, 64bit
> integer portability issues, etc.). What do you think?
>
Agree 101%, while working on this I've already seen a couple of places
where having int64 in zval instead of long were the right choice while
porting the string stuff. Like what Anthony says about working with the
string size in userspace, but the other parts of code will need it
simultaneously, too. For that we've already zend_intptr_t defined in
zend_types.h . Lets tweak zval definition and do it parallel.

>
>> Here's the branch:
>> https://github.com/ircmaxell/php-src/tree/string_size_refactor_take_2
>> And the diff:
>> https://github.com/ircmaxell/php-src/compare/string_size_refactor_take_2
>>
>>
>> If you want to help out, please let me know and let's try to coordinate
>> so we don't step on each other's toes...
>
> It would be awesome to add this fork to lxr, it can be amazingly
> helpful. From our side, we are testing and fixing (Weltling) it already, we
> will try to do it on regular basis to do not stay behind or do to do not
> have to debug a huge amount of changes to fix one bug or another (can be
> painful with this kind of changes).
>
It were awesome to put this work into git.php.net space and use lxr.

Best regards

Anatol

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to