leisner@arisia.Xerox.COM (Marty Leisner) (07/26/89)
Is this a valid C program? gcc 1.35 handles it fine on a sun386i --
everything else I've tried won't compile these odd constants.
/* This should print out
inf
-inf
NaN
*/
main()
{
printf("%f\n", 1.0/0.0);
printf("%f\n", -1.0/0.0);
printf("%f\n", 0.0/0.0);
}
marty leisner
leisner.henr@xerox.comgwyn@smoke.BRL.MIL (Doug Gwyn) (07/26/89)
In article <1925@arisia.Xerox.COM> leisner@arisia.Xerox.COM (Marty Leisner) writes: >Is this a valid C program? It's certainly not strictly conforming. Division by zero is handled in an implementation-dependent way, including fatal compile-time error. Some of us think the IEEE inf/Nan scheme is conceptually bogus anyway. However, given that you seem to have a use for these in your (non-portable) application, the only way I know of to safely obtain inf and NaN quantities is to do it at run time, not compile time. In your example that means not computing the quantities by some constant expression, but by one involving variables.
ari@eleazar.dartmouth.edu (Ari Halberstadt) (07/27/89)
In article <1925@arisia.Xerox.COM> leisner@arisia.Xerox.COM (Marty Leisner) writes: >Is this a valid C program? gcc 1.35 handles it fine on a sun386i -- >main() >{ > printf("%f\n", 1.0/0.0); > printf("%f\n", -1.0/0.0); > printf("%f\n", 0.0/0.0); >} Why on earth would anyone want to compile that :-)? I think it's quite legal C, but it's total giberish, since if the compiler compiled it, it would simply result in a divide by zero, which any normal maching would have a fit over. -- Ari Halberstadt '91, "Long live succinct signatures" E-mail: ari@eleazar.dartmouth.edu Telephone: (603)640-5687 Mailing address: HB1128, Dartmouth College, Hanover NH 03755
fieland@hobbiton.prime.com (07/27/89)
According to K. & R., if the second operand of the division operator
is zero, the result is undefined. Therefore, the compiler is free
to do what it wants with this.
On a more practical note, the following program will cause the sun 386i
cc compiler to print out Inf, -Inf, and -Nan: (sic)
/* This should print out
inf
-inf
NaN
*/
main()
{float f1, f2, f3, f4 = 0;
f1 = 1.0/f4;
f2 = -1.0/f4;
f3 = 0.0/f4;
printf("%f\n",f1);
printf("%f\n", f2);
printf("%f\n", f3);
}
Peggy Fieland
fieland@primerd.prime.comwalter@hpclwjm.HP.COM (Walter Murray) (07/28/89)
>>Is this a valid C program? >>main() >>{ >> printf("%f\n", 1.0/0.0); >> printf("%f\n", -1.0/0.0); >> printf("%f\n", 0.0/0.0); >>} >It's certainly not strictly conforming. Division by zero is handled in >an implementation-dependent way, including fatal compile-time error. Another interpretation is that it's a valid program, as long as you don't try to run it! An expression involving division by zero is not illegal unless that expression has to be evaluated, in which case behavior is undefined. Under ANSI C, I think it's clear that the following program is valid, and prints the value 1. main() { printf("%d\n", 2.0||1.0/0.0); } Walter Murray Not speaking for X3J11 ----------
walter@hpclwjm.HP.COM (Walter Murray) (07/28/89)
>Is this a valid C program? gcc 1.35 handles it fine on a sun386i -- >everything else I've tried won't compile these odd constants. >/* This should print out > inf > -inf > NaN >*/ > >main() >{ > printf("%f\n", 1.0/0.0); > printf("%f\n", -1.0/0.0); > printf("%f\n", 0.0/0.0); >} In our compiler (HP 9000 Series 800) we evaluate these expressions at compile time, produce a warning, and store the appropriate bit patterns for +/- infinity and NaN. That seemed to be the thing to do to conform with the spirit of IEEE 754. Note, however, that there is no standard for what these numbers look like when formatted with "%f". Walter Murray ----------
pierre@rhi.hi.is (Kjartan Pierre Emilsson) (07/28/89)
From article <14675@dartvax.Dartmouth.EDU>, by ari@eleazar.dartmouth.edu (Ari Halberstadt): > In article <1925@arisia.Xerox.COM> leisner@arisia.Xerox.COM (Marty Leisner) writes: >>Is this a valid C program? gcc 1.35 handles it fine on a sun386i -- >>main() >>{ >> printf("%f\n", 1.0/0.0); >> printf("%f\n", -1.0/0.0); >> printf("%f\n", 0.0/0.0); >>} > > Why on earth would anyone want to compile that :-)? > I think it's quite legal C, but it's total giberish, since if the compiler > compiled it, it would simply result in a divide by zero, which any normal > maching would have a fit over. Not so. If your math library uses IEEE floating point standard, then the following code will work perfectly: main() { double a,b,c; extern double atan(); a=1.0; b=0.0; c=a/b; c=atan(c); printf("%f\n",c); } and the output will be: 1.57080 ( That is: Pi/2 which is arctangens(infinity)!) I'm not sure wether this is a good behaviour to rely upon, but it works.
gwyn@smoke.BRL.MIL (Doug Gwyn) (07/29/89)
In article <14675@dartvax.Dartmouth.EDU> ari@eleazar.dartmouth.edu (Ari Halberstadt) writes: >... it would simply result in a divide by zero, which any normal >maching would have a fit over. Well, you see, the "maching" in question is not normal. It implements IEEE Std 754 floating-point arithmetic, which includes the notion that 1.0/0.0 is a representable "infinity" value suitable for further use in computation. Now, if you want to say that's a really sick notion, I'd be inclined to agree with you. The trouble is that it's widely adopted.
gwyn@smoke.BRL.MIL (Doug Gwyn) (07/29/89)
In article <660047@hpclwjm.HP.COM> walter@hpclwjm.HP.COM (Walter Murray) writes: >Under ANSI C, I think it's clear that the following program is >valid, and prints the value 1. >main() { printf("%d\n", 2.0||1.0/0.0); } I think that's right. (I remember the discussion but not the outcome!) But if there is a division by zero in a context where a constant-expression is required (e.g. array bound) then I think it's a compile-time violation. Really, I hope people don't try to write applications that depend on divide-by-zero behavior. They're just asking for the trouble that they'll undoubtedly eventually get.