[splint-discuss] How to check Uninitialized variable

[Jeff Johnson]

On May 12, 2009, at 1:43 PM, Michael Wojcik wrote:

>> From: splint-discuss-bounces at cs.virginia.edu [mailto:splint-discuss-
>> bounces at cs.virginia.edu] On Behalf Of Aaron Davies
>> Sent: Tuesday, 12 May, 2009 10:28
>>
>> On Tue, May 12, 2009 at 9:39 PM, Ludolf Holzheid <lholzheid at bihl-
>> wiedemann.de> wrote:
>>> On Tue, 2009-05-12 15:16:03 +0200, Nido wrote:
>>>> Here's a hack I used for another project
>>>>
>>>> /* Yes this is meant to be uninitialised */ unsigned int seed =
>>>> (unsigned int)&seed;
>>>
>>> Maybe you meant `seed' to be un-initialized, but you actually
>>> initialized it to `some arbitrary number not equal to zero'. The
> same
>>> could be achieved with e.g. "unsigned int seed = 17;".
>>
>> Isn't it non-deterministic though? Given the name, I assume that's
> what
>> he was trying to achieve.
>
> It may be non-deterministic, depending on the execution environment  
> - C
> makes no guarantees either way. But it's unlikely to have much, if  
> any,
> entropy.
>

There's a fundamental issue wrto static annotations (like splint) vs.
run-time instrumentation (like valgrind).

Identifying (and statically annotating) every possible path in
a program is -- in general -- infeasible.

Consider a code path that depends on how an application is configured.
Sure one can add assertions to indicate the domain of application
of splint annotations.

But are splint annotations the correct tool for eliminating  
uninitialized
variables?

Its rather easy to find uninitialized variables using valgrind instead.

All I really mean to point out is that splint can't find every flaw,
nor can valgrind. The combination of tools is far better than either.

73 de Jeff