Hi,
Zitat von "Omari Stephens" <xsdg@xxxxxxxxxxxxx>:
> On 04/21/2010 11:58 AM, Oliver Bandel wrote:
>> Zitat von "Tor Lillqvist"<tml@xxxxxx>:
>>
[...]
>> 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. ;-)
Ciao,
Oliver
_______________________________________________
Gimp-developer mailing list
Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
