Zitat von "Torsten Neuer" <tneuer@xxxxxxxxx>:
> Am Freitag, 23. April 2010 08:39:52 schrieb Oliver Bandel:
>> Zitat von "Sven Neumann" <sven@xxxxxxxx>:
>> > 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
> executed.
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.
Yes.
[...]
> 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.
Ciao,
Oliver
_______________________________________________
Gimp-developer mailing list
Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
