<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman,new york,times,serif;font-size:12pt"><div><br></div><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;">I mistakenly did not post my reply to David to the list as well...<br>Please examine this issue in terms relating to gcc compatibility... Thanks<br>Daniel<br><br><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><font size="2" face="Tahoma">----- Forwarded Message ----<br><b><span style="font-weight: bold;">From:</span></b> dan chap <dchapiesky@yahoo.com><br><b><span style="font-weight: bold;">To:</span></b> David Chisnall <theraven@sucs.org><br><b><span style="font-weight: bold;">Sent:</span></b> Mon, June 14, 2010 6:35:12 PM<br><b><span style="font-weight: bold;">Subject:</span></b> 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?<br></font><br>
<div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;">David,<br><br>"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"<br><br>is not applicable to all platforms nor the lli JIT environment.<br><br>My original post shows test results from all of the various modes of gcc and clang on ubuntu x86.<br><br>Please review the attached test code and shell script.<br><br>I realized after my initial post that the true question here is:<br><br>-------------------------<br>*** Should the code generator _enforce_ assumptions of the optimizer in Clang release mode?<br>-------------------------<br><br>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.....<br><br>A) the test program I submitted _shows_ gcc release mode functioning _as_expected_ and Clang release/debug/etc... __failing__ to produce accurate runtime behaviour.<br><br>B) the initial question I had was: should this behaviour be to extend compatibility towards gcc? <br><br>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.<br><br>Sincerely,<br><br>Daniel Chapiesky<br><br><div style="font-family: arial,helvetica,sans-serif; font-size: 13px;"><font size="2" face="Tahoma"><hr size="1"><b><span style="font-weight: bold;">From:</span></b> David Chisnall <theraven@sucs.org><br><b><span style="font-weight: bold;">To:</span></b> dan chap <dchapiesky@yahoo.com><br><b><span style="font-weight:
bold;">Cc:</span></b> cfe-dev@cs.uiuc.edu<br><b><span style="font-weight: bold;">Sent:</span></b> Sun, June 13, 2010 2:52:50 PM<br><b><span style="font-weight: bold;">Subject:</span></b> Re: [cfe-dev] RFC-0x000 - Should (automatic) local variables be initialized to 0 for the programmer?<br></font><br>
On 13 Jun 2010, at 19:28, dan chap wrote:<br><br>> Should (automatic) local variables be initialized to 0 for the programmer?<br><br>No.<br><br>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:<br><br>$ cat stack.c<br>int stack(void)<br>{<br> int a;<br> printf("%d\n", a);<br> a = 12;<br> return a;<br>}<br><br>int main(void)<br>{<br> stack();<br> return stack();<br>}<br>Liberator:tmp theraven$ gcc stack.c && ./a.out <br>0<br>12<br>12<br><br>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. <br><br>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. <br><br>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.<br><br>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.<br><br>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.<br><br>David<br><br>-- Sent from my Difference Engine<br><br><br><br></div></div>
</div><br>
</div></div>
</div><br>
</body></html>