Re: smbfs bug introduced at smbfs_vnops.c:1.58

From: Bruce Evans <bde_at_zeta.org.au>
Date: Mon, 11 Apr 2005 03:55:31 +1000 (EST)
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
Received on Sun Apr 10 2005 - 15:55:39 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:31 UTC