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