Hi Joe,
It does look as if you're right. I don't quite understand why the standard was written in such a way and not in a way which only makes the value itself undefined.
I think we can apply the patch. Does anyone have a problem with setting arbitrary numbers such as LONG_MAX/LONG_MIN for an undefined conversion?
Andi
At 08:54 AM 8/31/2004 +0100, Joe Orton wrote:
On Mon, Aug 30, 2004 at 04:40:13PM -0700, Andi Gutmans wrote: > At 11:17 PM 8/30/2004 +0100, Joe Orton wrote: > >On Mon, Aug 30, 2004 at 02:20:42PM -0700, Andi Gutmans wrote: > >> I know it's undefined but why is defining it to LONG_MAX/LONG_MIN any > >> better? It's not the kind of behavior which I think we should "define". > > > >C code which has undefined behaviour may segfault or suffer some other > >run-time exception; the compiler may arrange for it to print "I'm a > >fluffy pink rabbit" to stderr as a side-effect. > > Joe, > > I'm pretty sure if you read the C standard it'll say something about the > "value" being undefined, not about the behavior of the whole program being > undefined.
Andi, I checked the relevant parts of the C standard before writing the patch, I would not presume to waste your time with mere speculation or guesswork on such matters.
C99 section 6.3.1.4 "Real floating and integer" defines conversion of double to long, and says "If the value of the integral part cannot be represented by the integer type, the behavior is undefined." (as I in fact stated in my original mail).
Section 3.4.3 defines the term "undefined behaviour" in black and white. It's quite clear.
Regards,
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
