Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87852
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.176 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <02ba01d0dbfb$3de2c390$b9a84ab0$@belski.net>
References: <02a601d0dbed$2c828df0$8587a9d0$@belski.net>
	<CAL+t6cHdJNNySG0x76a1k_903XrFmfcCDHHH8LbmiTRNoQ3c4Q@mail.gmail.com>
	<02ae01d0dbf5$01c17330$05445990$@belski.net>
	<02b001d0dbf5$607ab7b0$21702710$@belski.net>
	<CAL+t6cEsfH6m6HPbr9KoenSA3N35spucpoE=norTWS9dKZJJNA@mail.gmail.com>
	<02ba01d0dbfb$3de2c390$b9a84ab0$@belski.net>
Date: Fri, 21 Aug 2015 21:38:38 -0400
Message-ID: <CAL+t6cFXSZ5WYCZ00=uBkiZqVNWcHh9SBu+Kgtnr-v0iP8sRyA@mail.gmail.com>
To: Anatol Belski <anatol.php@belski.net>
Cc: Dmitry Stogov <dmitry@php.net>, Xinchen Hui <xinchen.h@zend.com>, 
	Nikita Popov <nikita.ppv@gmail.com>, Pierre Joye <pierre.php@gmail.com>, 
	Bob Weinand <bobwei9@hotmail.com>, Jakub Zelenka <bukka@php.net>, 
	Matt Wilmas <php_lists@realplain.com>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c3d08c8b72b0051ddc714f
Subject: Re: [PHP-DEV] Overflow checks and integral vars comparison
From: theanomaly.is@gmail.com (Sherif Ramadan)

--001a11c3d08c8b72b0051ddc714f
Content-Type: text/plain; charset=UTF-8

On Fri, Aug 21, 2015 at 6:22 AM, Anatol Belski <anatol.php@belski.net>
wrote:

>
>
> > -----Original Message-----
> > From: Sherif Ramadan [mailto:theanomaly.is@gmail.com]
> > Sent: Friday, August 21, 2015 12:00 PM
> > To: Anatol Belski <anatol.php@belski.net>
> > Cc: Dmitry Stogov <dmitry@php.net>; Xinchen Hui <xinchen.h@zend.com>;
> > Nikita Popov <nikita.ppv@gmail.com>; Pierre Joye <pierre.php@gmail.com>;
> > Bob Weinand <bobwei9@hotmail.com>; Jakub Zelenka <bukka@php.net>; Matt
> > Wilmas <php_lists@realplain.com>; PHP Internals <internals@lists.php.net
> >
> > Subject: Re: [PHP-DEV] Overflow checks and integral vars comparison
> >
> > I think you're a little optimistic about how effective these macros
> would be for
> > overflow checks. Also, if we're talking ANSI C or C99, then size_t is
> always
> > unsigned, and as far as I know GCC 2.4 always treats it as such.
> > If we're trying to stick to C here anyway.
> >
> > As far as architecture specific stuff I would much rather rely on using
> the built-in
> > GCC overflow checks here https://gcc.gnu.org/onlinedocs/gcc/Integer-
> > Overflow-Builtins.html
> >
> Yes, this is a good idea as a further extension of such mechanics. However
> you're talking about a different topic that I've proposed now.
> > ... as they are much safer and likely going to be far more performant
> than doing
> > all these casts everywhere. Not to mention the fact that you can
> actually catch
> > the overflow at the actual arithmetic level, where it's safe, and
> hopefully be able
> > to rely on the ISA's overflow or carry bits. If we're trying to detect
> overflows or
> > wraps after the fact, you don't add much in the way of security. For
> example,
> > I'm not at all sure how (zlong) < (zend_long)INT_MIN will ever detect an
> > overflow.
> >
> What I'm talking about is detecting whether a variable of zend_long or
> size_t is in the safe range to be passed to a signature requiring int. This
> is quite a minimalistic start in this direction.
>

I see. So you're not actually doing overflow checks then? Because at the
point you'd be checking this zend_long or size_t it could have already
overflowed or wrapped. The subject may have misled me to understand
differently.


>
> Also please remember that there is not only GCC in the world. It is quite
> another topic to implement overflow checks portable ways, some intrinsics
> can be here of some help, too. But rather than hitting quite a global
> thing, I'd rather start on what is simple and is for sure an issue at least
> with some dependency libs.
>

Of course, but the ASM can also be ported to other architectures and
wrapped in #ifdef for non x86 and MSVC or other compilers, for example.
It's not impossible to achieve some sane degree of portability there. I see
Andrea already worked on some of this in zend_operators.h for example
https://github.com/php/php-src/blob/ee2e1691080dad2a3110107dd8bd02ee23b41fa0/Zend/zend_operators.h#L437

Of course, making integer overflow checks safe and efficient is by no means
easy on every given architecture, but surely we could aim to support at
least the broadest current architectures at first and fall back to C
overflow checks if necessary.

I agree with starting simple. I'm honestly not sure of the effectiveness of
what you're proposing to be honest, but maybe with a PR I'd be able to wrap
my head around it a little more.



>
> Regards
>
> Anatol
>
>

--001a11c3d08c8b72b0051ddc714f--