From owner-svn-src-all@FreeBSD.ORG Tue Oct 9 21:30:06 2012 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 566FF315; Tue, 9 Oct 2012 21:30:06 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id 02BC98FC18; Tue, 9 Oct 2012 21:30:05 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.5/8.14.5) with ESMTP id q99LPc4a068010; Tue, 9 Oct 2012 14:25:38 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.5/8.14.5/Submit) id q99LPcLI068009; Tue, 9 Oct 2012 14:25:38 -0700 (PDT) (envelope-from sgk) Date: Tue, 9 Oct 2012 14:25:38 -0700 From: Steve Kargl To: Eitan Adler Subject: Re: svn commit: r241373 - head/lib/libc/stdlib Message-ID: <20121009212538.GA67848@troutmask.apl.washington.edu> References: <201210091425.q99EPFS6020787@svn.freebsd.org> <507451DE.9060909@freebsd.org> <50746BF8.5010307@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: svn-src-head@freebsd.org, theraven@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Andrey Chernov X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 21:30:06 -0000 On Tue, Oct 09, 2012 at 04:23:59PM -0400, Eitan Adler wrote: > On 9 October 2012 14:24, Andrey Chernov wrote: > > I don't have ISO9899 nearby, could you directly quote mentioned > > sections, please? > > Accesses to volatile object (a) produce side effects (b) have > implementation defined values. > > A more careful re-reading of the relevant section leads me to believe > I may have been wrong > with this comment. It isn't made explicit, but the C standard never > says that accesses > to uninitialized volatile is defined. On the other hand, the existence > of "const volatile" proves me wrong. > Interestingly, clang and gcc disagree on whether to warn: > > [8084 eitan@radar ~ ]%gcc46 -Wall -Wextra -ansi -pedantic a.c > [8089 eitan@radar ~ ]%clang -Wall -Wextra -ansi -pedantic a.c > a.c:3:9: warning: variable 'a' is uninitialized when used here > [-Wuninitialized] Given that I cannot see a.c, I'll assume that 'a' is declared with a volatile-qualified type. In that case, it appears that clang has a bug. From 6.7.3, page 109 in n1256.pdf, one finds: An object that has volatile-qualified type may be modified in ways unknown to the implementation or have other unknown side effects. Therefore any expression referring to such an object shall be evaluated strictly according to the rules of the abstract machine, as described in 5.1.2.3. Furthermore, at every sequence point the value last stored in the object shall agree with that prescribed by the abstract machine, except as modified by the unknown factors mentioned previously. 116) 116) A volatile declaration may be used to describe an object corresponding to a memory-mapped input/output port or an object accessed by an asynchronously interrupting function. Actions on objects so declared shall not be ``optimized out'' by an implementation or reordered except as permitted by the rules for evaluating expressions. Clang has no way of determining if 'a' is initialized or not. If David is correct that 'junk' is optimized out by clang/llvm, then it seems that clang violates footnote 116. Yes, I know it is non-normative text. > I still don't like volatile though here for the other reasons > mentioned. In general, the entire piece of code should be replaced > with something that can't fail, so this is a moot point. Agreed. -- Steve