In general, PHP always keeps the values as doubles if it detects that the value is too low. This macro is only used when you force it, and I don't think setting arbritrary values is any better than undefined.
Andi
At 09:24 PM 8/30/2004 +0100, Joe Orton wrote:
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
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
