Maybe I'm missing something here, but how do these macros detect overflow
exactly? If the check is done on the actual result and not the operands
then it's not a good overflow check. Additionally, why wouldn't overflow
checks be needed on 32-bit architecture, or any other architecture for that
matter? Integers can overflow there too.

On Fri, Aug 21, 2015 at 4:41 AM, Anatol Belski <anatol....@belski.net>
wrote:

> Hi,
>
> Resending this as missed internals at the start.
>
> I was lately rethinking some part of the 64-bit RFC, and also seeing now
> Jakub's work on catching overflows in ext/openssl and Matt Williams
> suggestions on it (which was going a bit more global over it). So I came up
> with these macros with two goals
>
> - standardize the overflow checks
> - do actualy checks only on architectures where it's needed
> - simplify the checks where external libs (openssl, libxml, etc.) use firm
> datatypes like int
>
> #if SIZEOF_INT == SIZEOF_ZEND_LONG
> # define ZEND_LONG_INT_OVFL(zl) (0)
> # define ZEND_LONG_INT_UDFL(zl) (0)
> #else
> # define ZEND_LONG_INT_OVFL(zlong) ((zlong) > (zend_long)INT_MAX) # define
> ZEND_LONG_INT_UDFL(zlong) ((zlong) < (zend_long)INT_MIN) #endif
>
> #define ZEND_SIZE_T_INT_OVFL(size) ((size) > (size_t)INT_MAX)
>
> So having it like
>
> If (ZEND_LONG_INT_OVFL(x)) {
>         return;
> }
>
> Compiler would eliminate the branch automatically on 32-bit and ILP64.
>
> Some other macros to do signed/unsigned comparison, these can be extended.
>
> #define ZEND_SIZE_T_GT_ZEND_LONG(size, zlong) ((zlong) < 0 || (size) >
> (size_t)(zlong)) #define ZEND_SIZE_T_GTE_ZEND_LONG(size, zlong) ((zlong) <
> 0
> || (size) >= (size_t)(zlong)) #define ZEND_SIZE_T_LT_ZEND_LONG(size, zlong)
> ((zlong) >= 0 && (size) < (size_t)(zlong)) #define
> ZEND_SIZE_T_LTE_ZEND_LONG(size, zlong) ((zlong) >= 0 && (size) <=
> (size_t)(zlong))
>
> IMHO these and maybe more are missing after the 64-bit RFC. Do you think
> they would make sense? Or would make sense now, or later in master?
>
> Thanks
>
> Anatol
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Reply via email to