From owner-freebsd-fs@FreeBSD.ORG Sun Apr 10 17:55:39 2005 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 029D116A4CE; Sun, 10 Apr 2005 17:55:39 +0000 (GMT) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 57B8D43D2D; Sun, 10 Apr 2005 17:55:38 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86])j3AHtXml022309; Mon, 11 Apr 2005 03:55:33 +1000 Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) j3AHtVIo014029; Mon, 11 Apr 2005 03:55:32 +1000 Date: Mon, 11 Apr 2005 03:55:31 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Chuck Swiger In-Reply-To: <42595E04.60705@mac.com> Message-ID: <20050411032601.S55302@delplex.bde.org> References: <200504100251.j3A2pLEH055107@sana.init-main.com> <1892195662.20050410140423@andric.com><42595E04.60705@mac.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-fs@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: smbfs bug introduced at smbfs_vnops.c:1.58 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2005 17:55:39 -0000 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