On 02/18/2013 03:28 PM, Jeffrey Walton wrote:
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 ;)
I like when things just work, without weird dependencies. But the trade-off
sounds reasonable to me in this case, but I am not a GCC developer and
have no moral right to justify this claim.
Instead of joining your request for a new GCC feature I have a suggestion to
you. How about writing a plug-in for GCC to do that? I am no expert, but
writing a melt plug-in does not sound too complicated:
http://gcc-melt.org/
It is possible that you could add an initialization to every
uninitialized variable
in a simple melt plug-in.
I have never written a plug-in so I may be completely wrong, and it is not
that simple. I think that it is worth having a look.
Michael
