smbfs bug introduced at smbfs_vnops.c:1.58

[Bruce Evans]

On Sun, 10 Apr 2005, Chuck Swiger wrote:

> Daniel Ellard wrote:
>> On Sun, 10 Apr 2005, Dimitry Andric wrote:
> [ ... ]
>> At least the gcc folk now do detect this old chestnut:
>> 
>> 	{
>> 	    int a;
>> 
>> 	    a /= 0;
>> 	}
>> 
>> which was used to provoke arguments in compiler
>> classes for many years.  (Optimized, nothing happens.
>> Unoptimized, a division-by-zero error happens...)
>
> Great example.
>
> If the optimized code fails to generate a division-by-zero error here, the 
> optimizer is buggy.  (I won't quote Aho, Sethi, and Ullman again.... :-)

No, the behaviour is undefined.  The compiler can do anything.  gcc now
emits a warning even with -O0.

A similar example with "double a;" is more interesting.  This also
gives undefined behaviour (C99 6.5.5[#5]).  However, this is bogus if
there is a floating point infinity.  C99 has support for IEEE floating
point and it is clearly intended that the behaviour of 1.0/0.0 is to
give +Inf and raise the divide-by-zero exception, but I couldn't see
anywhere in the C99 draft n869.txt where this is spelled out (raising of
the divide-by-zero exception is spelled out for lots of math functions
but doesn't seem to be mentioned for plain division).

Also, in C99 with IEEE FP support, "#pragma STDC FENV_ACCESS *" should
affect the behaviour.  I'm not sure of the details, but think that
programs can only depend on getting the divide-by-zero exception if
FENV_ACCESS is ON.  gcc still doesn't support this pragma, so it does
several wrong things with FENV_ACCESS ON:
- for "a = 1.0 / 0.0;", it evaluates 1.0 / 0.0 at compile time (even
   with -O0) so it never raises a divide-by-zero exception.
- "a /= 0.0;" where "a" is not otherwise used is not dead code, since
   it should have the side effect of raising the exception, but gcc
   considers this code to be dead.

Bruce