Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70438
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.128.50 as permitted sender)
MIME-Version: 1.0
Sender: jakub.php@gmail.com
In-Reply-To: <f07b1f4e5add2f17b359f5a49fa9ab79.squirrel@webmail.klapt.com>
References: <ac356e6f51447e9d17b12e4916135e68.squirrel@webmail.klapt.com>
	<CAEKnhAG-SvNpQ5iHdFDL7nf5=8j+H+2jgYE+wX-qq+hjJMJ0kw@mail.gmail.com>
	<f07b1f4e5add2f17b359f5a49fa9ab79.squirrel@webmail.klapt.com>
Date: Wed, 27 Nov 2013 10:24:11 +0000
Message-ID: <CAEKnhAHftDx3B+QgeAOsfQEmcd9uvoT1mBu_Wej9pKqrPd2sXw@mail.gmail.com>
To: Anatol Belski <ab@php.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c2bd8480ce6104ec25ffe0
Subject: Re: [PHP-DEV] size_t and 64 bit integer branch
From: bukka@php.net (Jakub Zelenka)

--001a11c2bd8480ce6104ec25ffe0
Content-Type: text/plain; charset=ISO-8859-1

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

--001a11c2bd8480ce6104ec25ffe0--