C/C++ Option to Initialize Variables?

[Michael Veksler]

On 02/18/2013 03:28 PM, Jeffrey Walton wrote:
> On Mon, Feb 18, 2013 at 7:42 AM, Michael Veksler
> <mveksler@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