[splint-discuss] How to check Uninitialized variable

[Nido]

2009/5/12 Jeff Johnson <n3npq at mac.com>:
>
> 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.

I see now.

Using Fedora Linux 10 it does give a different number every time it is
executed, but usually relatively close to some certain value. Further
along the line it xor'd with the current second and nanosecond before
it's fed to the srandom function.

> 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
> _______________________________________________
> splint-discuss mailing list
> splint-discuss at mail.cs.virginia.edu
> http://www.cs.virginia.edu/mailman/listinfo/splint-discuss
>