Re: size_t and 64 bit integer branch

Hi Anatol On Wed, Nov 27, 2013 at 8:37 AM, Anatol Belski <ab@php.net> 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