Zitat von "Torsten Neuer" <tne...@inwise.de>:
> Am Freitag, 23. April 2010 08:39:52 schrieb Oliver Bandel:
>> Zitat von "Sven Neumann" <s...@gimp.org>:
>> > Hi,
>> > On Thu, 2010-04-22 at 14:38 +0200, Fredrik Alströmer wrote:
>> >> For the record, I'm not necessarily against setting a predefined value
>> >> to variables sometimes. I'm just against doing it for the wrong
>> >> reasons, and I'd much rather have the compiler say "Warning: might be
>> >> used uninitialized in this context" as a part of the static analysis,
>> >> rather than chase down the bug where a value is 0 at run time
>> >> (remember, I'm primarily talking corner cases here).
>> > Totally agreed. I also prefer the compiler telling me that a refactoring
>> > I've just done is not correct because I forgot to initialize a variable
>> > in a code path. This has happened to me and the compiler warning caught
>> > some potential bugs. If we would always initialize all variables this
>> > mistake would have gone unnoticed.
>> If this case would be undetected by the compiler, but you have
>> initialized it to your EXCEPTIONAL value at the same line, at which
>> the variable is defined,
>> then - when running the code, it would have shown you your problem.
> You are comparing a bug turning up when actually running the code vs. turning
> up when compiling it. I prefer to find and fix it *before* the code gets
I do prefer this too.
> Whenever a compiler is able to tell about a possible bug development is
> quickened. Which is one of the reasons some languages have explicitly been
> designed to allow for good static code evaluation.
> Ignoring warnings "just for testing" is bad style and contra-productive. Any
> serious programmer doing that should be slapped with a wet trout.
I have seen this all to often at work.
"It's just a warning..."
>> The other case is: values change during the meantime.
>> If you reset them to the exceptional values after usage,
>> especially I mean pointers here, that's a good idea.
> Agreed with that. But then again, optimally these pointers themselves should
> not exist any more (which means you can't dereference them).
> What you seem to be talking about here is the use of global
> variables that get
> re-used over and over. Resetting those to sane values is absolutely a must,
> but one should avoid the use of global variables whereever possible in the
> first case.
Let it be a field in a structure that will be used even after the free.
And if normally after the free that pointer will not be used...
be sure, one day it will be re-used, and the NULL-check then fails. :)
That's going to be fun. :)
> In case of library functions dealing with pointers, on the other hand, one
> cannot be sure whether the pointer itself is destroyed after the memory is
> freed. So setting the pointer to a sane value is a must and cannot
> be avoided.
OK, so I see you agree.
Many people are maybe not aware of that problem, I would think.
Gimp-developer mailing list