On Mon, Feb 18, 2013 at 7:42 AM, Michael Veksler <mveks...@tx.technion.ac.il> wrote: > On 02/18/2013 02:02 PM, Alec Teal wrote: >> >> On 18/02/13 11:40, Jeffrey Walton wrote: >>> >>> Hi All, >>> >>> >>> http://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html#C-Dialect-Options >>> >>> Is there an option to initialize variables to known values in a C/C++ >>> program? >>> >>> My use case is 'debug' builds and finding use of uninitialized values >>> that get lucky by being 0 most of the time. For example: >>> >>> void DoSomeithWithFoo(FOO** ppf) { >>> if(ppf && *ppf == NULL) { >>> *ppf = new FOO; >>> ... >>> } >>> } >>> >>> FOO* p; >>> DoSomeithWithFoo(&p); >>> >>> So I would like something that initializes to known, but non-NULL, >>> such as 0xCDCDCDCD or 0xFDFDFDFD (similar to Visual Studio behavior). >>> >> ... >> >> > I believe Jeff thinks the above is a bug in *his* code, and he wants a flag > to > help him spot it. By assigning non-NULL values to unintialized variables > will, > supposedly, make the code behave wrongly, making it easier to detect. The reason I went looking for the flag is someone asked about a crash on the OpenSSL mailing list. I knew it was due to an uninitialized field (but they did not realize the value was not initialized). I wanted to suggest a quick way to find what was not initialized.
How much code do you think would break because folks depend on getting a 0 due to good graces or side effects (for example, the memory manager returning a zeroized page)? What if the ".BSS" section was initialized to 0xFF rather than a page full of NULLs? > I agree that having gcc deliberately put garbage into uninitialized > variables can > be very helpful in shortening the compile-test-debug-fix loop. I run > valgrind only > occasionally, even though I run unit-tests after every modification. This > means > that bugs due to unintialized memory are sometimes detected many days after > they were first introduced, which makes it more difficult to understand the > bug. Testing code compiled with this flag will probably result in less bugs > of > this kind left to testing by valgrind. Yes, it's a great feature of Visual Studio. It helps you find the point of first failure (or the potential point) quickly. > I see the main issue with such flags in their interaction with tools like > valgrind. Such a flag could defeat valgrind's algorithm for detecting > unintialized local variables, unless it is made aware of the flag > (which I don't see how it could be done, without special hints from gcc). When building for tools such as Valgrind, don't specify the flag ;) Jeff
