From owner-freebsd-fs@FreeBSD.ORG Sun Apr 10 18:04:55 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 6F90D16A4CF for ; Sun, 10 Apr 2005 18:04:55 +0000 (GMT) Received: from av3-2-sn4.m-sp.skanova.net (av3-2-sn4.m-sp.skanova.net [81.228.10.113]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1D4943D1D for ; Sun, 10 Apr 2005 18:04:53 +0000 (GMT) (envelope-from ertr1013@student.uu.se) Received: by av3-2-sn4.m-sp.skanova.net (Postfix, from userid 502) id D6E3037E51; Sun, 10 Apr 2005 20:04:52 +0200 (CEST) Received: from smtp4-2-sn4.m-sp.skanova.net (smtp4-2-sn4.m-sp.skanova.net [81.228.10.180]) by av3-2-sn4.m-sp.skanova.net (Postfix) with ESMTP id C5A7037E42 for ; Sun, 10 Apr 2005 20:04:52 +0200 (CEST) Received: from falcon.midgard.homeip.net (h201n1fls24o1048.bredband.comhem.se [212.181.162.201]) by smtp4-2-sn4.m-sp.skanova.net (Postfix) with SMTP id 526A237E46 for ; Sun, 10 Apr 2005 20:04:52 +0200 (CEST) Received: (qmail 1026 invoked by uid 1001); 10 Apr 2005 18:04:50 -0000 Date: Sun, 10 Apr 2005 20:04:50 +0200 From: Erik Trulsson To: Chuck Swiger Message-ID: <20050410180450.GA963@falcon.midgard.homeip.net> Mail-Followup-To: Chuck Swiger , Daniel Ellard , freebsd-fs@freebsd.org, freebsd-current@freebsd.org References: <200504100251.j3A2pLEH055107@sana.init-main.com> <20050410074009.N66651@bowser.eecs.harvard.edu> <1892195662.20050410140423@andric.com> <20050410082945.H66651@bowser.eecs.harvard.edu> <42595E04.60705@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42595E04.60705@mac.com> User-Agent: Mutt/1.5.9i 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 18:04:55 -0000 On Sun, Apr 10, 2005 at 01:10:28PM -0400, 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. Not at all. Division by zero means undefined behaviour (at least in C.) Undefined behaviour means *anything* may happen - including no error happening. A compiler optimizing away the division-by-zero is perfectly correct in doing so. (It is also perfectly correct to not optimize away the error.) > (I won't quote Aho, Sethi, and Ullman again.... :-) No, please don't - especially since that quote you are so fond of isn't *quite* correct - an optimizer is allowed to change the output of a program as long as the new output is also correct according to the language specification. (Language specifications often do not specify every detail, with the result that for a given program it can be the case that more than one output can be correct. In C any instance of undefined behaviour in a program means that *no* aspect of the program is defined and therefore all different outputs will be equally correct.) -- Erik Trulsson ertr1013@student.uu.se