[cfe-dev] Fw: RFC-0x000 - Should the code generator _enforce_ assumptions of the optimizer in Clang release mode? PREVIOUSLY Should (automatic) local variables be initialized to 0 for the programmer?

[Török Edwin]

On 06/16/2010 09:05 PM, dan chap wrote:
> 
> I mistakenly did not post my reply to David to the list as well...
> Please examine this issue in terms relating to gcc compatibility... Thanks
> Daniel
> 
> ----- Forwarded Message ----
> *From:* dan chap <dchapiesky at yahoo.com>
> *To:* David Chisnall <theraven at sucs.org>
> *Sent:* Mon, June 14, 2010 6:35:12 PM
> *Subject:* Re: [cfe-dev] RFC-0x000 - Should the code generator _enforce_
> assumptions of the optimizer in Clang release mode? PREVIOUSLY Should
> (automatic) local variables be initialized to 0 for the programmer?
> 
> David,
> 
> "As a security precaution, to prevent information leakage between
> processes, memory acquired from the kernel is initialized to 0 before
> being handed to the userspace program.  This means that the entire stack
> is initially 0"
> 
> is not applicable to all platforms nor the lli JIT environment.
> 
> My original post shows test results from all of the various modes of gcc
> and clang on ubuntu x86.
> 
> Please review the attached test code and shell script.
> 
> I realized after my initial post that the true question here is:
> 
> -------------------------
> *** Should the code generator _enforce_ assumptions of the optimizer in
> Clang release mode?
> -------------------------
> 
> The assertion "This means that the optimizer is free to assume that they
> have any value that it wishes.  It may assume that the value is 0, 123,
> or any other value that would produce faster code.  It does not
> matter."  cannot be applicable unless the runtime behaviour is as
> expected and.....

Have you tried declaring a pointer?
It is not initialized to NULL, it is 0x4 for me for example.

> 
> A) the test program I submitted _shows_ gcc release mode functioning
> _as_expected_ and Clang release/debug/etc... __failing__ to produce
> accurate runtime behaviour.

You already have undefined behaviour with gcc: -O0 doesn't init to 0 (if
you run it under valgrind you'll see a lot of warnings), the fact that
with release mode they happen to be 0 is just a coincidence.

GCC doesn't guarantee that it will init local vars to 0 when you
optimize, and in fact it doesn't.
In fact if you run GCC with -Wall it'll warn you that your local vars
are not initialized.

If you are worried that some nonconforming code will be miscompiled, you
can use -Werror=uninitialized, that'll make sure that you are not using
uninitialized values, and if you are your program will fail to compile.
The correct thing to do is to fix those programs
(although -Wuninitialized has some false positive warnings when the
variable is initialized on all code paths before use, gcc just can't
determine that).

> 
> B) the initial question I had was: should this behaviour be to extend
> compatibility towards gcc?

clang's -Wuninitialized should warn about these cases, thats all the
compatibility that is needed.

Best regards,
--Edwin