Re: Testing on NULL an unitialized values

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



A couple of very small coins.

On Thu, Apr 22, 2010 at 06:55, Martin Nordholts <enselic@xxxxxxxxx> wrote:
> On 04/22/2010 03:54 AM, Marc Lehmann wrote:
>> On Wed, Apr 21, 2010 at 08:14:33PM +0200, Martin Nordholts<enselic@xxxxxxxxx>  wrote:
>>> The compiler doesn't catch all cases, like this one:
>>>
>>> #include<stdio.h>
>>> int main(int argc, char **argv)
>>> {
>>>     int var;
>>>     if (argc == 2)
>>>       var = 42;
>>>     printf ("var = %d", var);
>>>     return 0;
>>> }
>>
>> 1. initialising var will not fix the bug, if there is any.
>
> It won't, but it will make the bug consistently occur, which is a big plus.
>
>
>> 2. initialising var will prevent other static analysers
>>     to diagnose a possible problem.
>
> The problem to diagnose would be that of using an initialized variable,
> no? The fix would then be to initialize the variable.

I think what he's trying to say here is that initializing it to 0 is
still uninitialized. Just deterministicly so. And no valgrind, or
static analyzers will notice that you're reading an uninitialized
zero. The fix would be to initialize the variable in all possible
execution paths, but not necessarily to 0.

>> 3. initialising var will prevent "weird effects"
>>     and just *might* decrease chances of finding the bug further.
>
> Why would you want "weird effects" in software? That's exactly what you
> don't want. At worst, a bug should manifest itself by making a program
> not do what it was intended to do, not doing something unpredictable.

Undeterministic behavior will expose a bug, deterministic but slightly
wrong will probably hide it.

>>> Since use of uninitlized variables very well can cause severe and
>>> hard-to-reproduce crashes, and since unpredictability never is a good
>>
>> Actually, it's easy to diagnose those bugs though, just look at the
>> coredump.
>
> The coredump gives you the state of the program when it crashed, not the
> cause leading up to the crash, which could have been an uninitlized
> local variable that's no longer in any stack frame.
>
>
>> Yes, don't do it unnecessarily, it tends to hide bugs.
>
> Rather "As a rule of thumb, initialize local variables.". As always
> there are cases where it's better not to initialize local variables.

The compiler is actually smart enough to give you a warning "might be
used uninitialized", always initializing to something will hide that
warning. And you'll use your uninitialized value (which will always be
zero, or whatever) unaware of that it's not sensibly initialized.

Fredrik.
_______________________________________________
Gimp-developer mailing list
Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


[Index of Archives]     [Video For Linux]     [Photo]     [Yosemite News]     [gtk]     [GIMP for Windows]     [KDE]     [GEGL]     [Gimp's Home]     [Gimp on GUI]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux