Re: size_t and 64 bit integer branch
Hi Anatol
On Wed, Nov 27, 2013 at 8:37 AM, Anatol Belski <[email protected]> wrote:
>
> your patch looks fine. Unfortunately I've overseen your mail in the daily
> flood and made some changes to openssl too. Why didn't you update the wiki
> page by going on? It's exactly for the purpose of knowing what's currently
> going on :) In any case, could you please merge with the current state and
> do a PR? I'll merge it then.
>
> One thing though about openssl and issues you mention in the gist - the
> 'int' vs. php_int_t overflows on 64 bit should be fixed on run time
> checking against INT_MAX. Maybe that's what you could extend for the
> openssl ext. That's an issue in many other libs too.
>
> Thanks for you work
>
> Anatol
>
>
I quickly looked on your commit and think that we mostly did the same stuff
:). Sorry for not updating the wiki, thought that will be better if I email
you first.
However there few extra fixes in my commit and some extra fixes in your
commits so I will merge them.
php_int_t vs int fixes will be quite easy. I'll do that. The bigger task is
int vs size_t (zend_str_size...) - signed vs unsigned. For some cases
(encryption, digest and other ctx updates) this can be fixed by splitting
the processing into more ctx updates. I think this could be useful on 32bit
when someone tries to encrypt more than 1 << 32 string. In that case, using
one update (as it is now) would fail. Other cases should probably generate
an error as there are not useful anyway. There few other case that I need
to look at as well (bio_buf_st->length, ASN_STRING length retval...).
I can assign it to myself in the wiki and set status "in progress" and when
it's done, I will update it and send PR. Is that ok?
Jakub
Thread (8 messages)