Zitat von "Omari Stephens" <x...@csail.mit.edu>:

> On 04/21/2010 11:58 AM, Oliver Bandel wrote:
>> Zitat von "Tor Lillqvist"<t...@iki.fi>:


>> Even only temporarily valies, if set to a certain value,
>> like 0 or NULL, will help in finding problems.
>> The mentioned function just was an example.
>> Uninitialzed values I see nearly everywhere in the code.
>> Dereferencing NULL is easy to find, because it crashes early.
> Hi, Oliver
> Have you programmed with glib before?

No, I'm new to glib.
I had it in mind since a while, because it also provides different  
kind's of trees.
But only now I have real contact to it.

> A lot of defensive programming
> techniques differ between straight C and C-with-glib.  For instance, the
> guards at the top are common, and (I imagine)
> gimp_context_copy_properties has similar guards.  As such, it's the job
> of the called function, not the caller, to check if a pointer they want
> to dereference is NULL.

Of course the called function has to test it on NULL/non-NULL.

But the function that creates a pointer does it's job best, if it
starts with a NULL right at the time of the definition.

My rule of thumb, which has helped me a lot is: ALWAYS INITIALIZE,
even if some lines later you assign a value.

But if you forget this part, or change code and the assignment is lost  
by accident, then there is a pointer that is NOT NULL.

Result: your tests on NULL fails!

So: all your gurading is disabled, if there is an unitialized pointer.

> This has the advantage that you don't check a pointer for NULL 10 times
> across 10 different function calls when you only use it once, all the
> way at the bottom.

I prefer checking it ten times   to checking it 0 times ;-)

> Of course, if you actually dereference a value (like
> the template pointer in the snippet you posted), you should test it
> before you dereference it.

The test against NULL will fail, if you forgot to assign a value.

If the value is assigned at definition (NULL for a pointer),
this makes the checks working always.

Maybe I had it not very good explained in my first mail,
what I mean.

So, I hope I have clarified it.

> In short, you might want to see what sort of defensive techniques are
> customary or appropriate for a given context before concluding that
> we're programming blind.

I didn't say blind programming.

But maybe also switching the light on is a god idea. ;-)


Gimp-developer mailing list

Reply via email to