Re: size_t and 64 bit integer branch

On Wed, November 27, 2013 11:24, Jakub Zelenka wrote: > 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 > Jakub, the ctx update issue might be interesting for the current codebase as well, I think. A simpler way were the range check for INT_MAX as it's always possible to pass a smaller chunk from the userland. The size_t vs. signed might can get an issue of course, that's the common thread of course so should be fixed where applicable. I could only welcome you to update the wiki with the task you can take on, whether nicer or simpler solution :) Thanks Anatol