[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?

[dan chap]

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.....

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

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

Please, examine my attachment, look at the differences in the various builds.  If you are on windows, I would love to see the results from visual C.

Sincerely,

Daniel Chapiesky



________________________________
From: David Chisnall <theraven at sucs.org>
To: dan chap <dchapiesky at yahoo.com>
Cc: cfe-dev at cs.uiuc.edu
Sent: Sun, June 13, 2010 2:52:50 PM
Subject: Re: [cfe-dev] RFC-0x000 - Should (automatic) local variables be initialized to 0 for the programmer?

On 13 Jun 2010, at 19:28, dan chap wrote:

> Should (automatic) local variables be initialized to 0 for the programmer?

No.

I believe that you are confusing several issues here.  First, you are assuming that GCC is initializing local values to 0.  This is absolutely and categorically not the case.  Take this trivial test as an example:

$ cat stack.c
int stack(void)
{
    int a;
    printf("%d\n", a);
    a = 12;
    return a;
}

int main(void)
{
    stack();
    return stack();
}
Liberator:tmp theraven$ gcc stack.c && ./a.out 
0
12
12

As you can see, a is initialized to 0 the first time stack() is called, but not the second time?  Why is this?  Because the memory for the stack is acquired from the OS.  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.  

In this function, however, the second time that it is called, the first call has already written a value of 12 to that stack slot, so reusing it you find that the old value is already there.  If you had called another function in the middle, then this would not be the case - its on-stack values would be there instead.  

Secondly, you are assuming that the fact that GCC assumes the stack values to be 0 but they are not is an insidious bug.  It is not, it is a side effect of undefined behaviour.

Uninitialized variables have an undefined value.  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, from the point of view of standards conformance, whether this assumption is correct, because the result of comparing a defined value to an undefined value is, itself, undefined and so any behaviour is valid.

Finally, setting all locals to 0 initially would incur a speed penalty, which is the last thing that you want in release code.  You don't need the static analyser to tell you that you are doing something stupid - both clang and GCC can issue a warning if you use a variable before initializing it.

David

-- Sent from my Difference Engine


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20100616/ab816d06/attachment.html>