On Mon, Aug 30, 2004 at 12:32:59PM -0700, Andi Gutmans wrote:
> Hi Joe,
>
> It seems like your patch doesn't really fix anything. How is rounding to
> LONG_MAX/LONG_MIN any better?
The C standard says that when converting a double to a long, if the
integral part of the double is outside the range which can be
represented by a long, the conversion has undefined behaviour.
#define DVAL_TO_LVAL(d, l) (l) = (d) > LONG_MAX ? (unsigned long) (d) : (long) (d)
where d is a double and l is a long: so this has undefined behaviour for
values of d greater than ULONG_MAX or smaller than LONG_MIN.
#define DVAL_TO_LVAL(d, l) do { \
if ((d) > LONG_MAX) { \
l = LONG_MAX; \
} else if ((d) < LONG_MIN) { \
l = LONG_MIN; \
} else { \
l = (d); \
} \
} while (0)
has well-defined behaviour for all values of 'd', since it will never
attempt to assign a value to 'l' which cannot be represented by a long.
> Maybe you can explain in more detail what this gcc bug you are hitting is?
It seems to be an IA64-specific optimisation bug, it's really incidental
to the fact that the current code is dubious. GCC evaluates the
expression as either 0 or LONG_MIN if d is negative, depending on -O
level. (Which is fairly nasty)
joe
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
