svn commit: r241373 - head/lib/libc/stdlib

[Steve Kargl]

On Tue, Oct 09, 2012 at 04:23:59PM -0400, Eitan Adler wrote:
> On 9 October 2012 14:24, Andrey Chernov <ache at freebsd.org> 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 at radar ~ ]%gcc46 -Wall -Wextra -ansi -pedantic a.c
> [8089 eitan at 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