Zitat von "Tor Lillqvist" <tml@xxxxxx>:
>> You are right, that in some seldom situations it might make sense
>> to initialize values to other start values. But they should always be
>> predictable.
>
> You didn't get the reasoning about letting the compiler, or valgrind,
> catch use of uninitialized variables, did you?
I got it.
But the compiler throws a warning and not an error on it.
So, it's possible to get running code.
>
>> The same is here: a NULL-pointer is an exception.
>
> Only if you try to dereference it.
No, I mean exception in a different way.
It's an exception even if you don't dereference it,
because it will be one, if you dereference it.
Dereferencing a pointer that is not NULL, but contains nonsense,
not necessarily pops up as a problem.
But it will be a problem, when the code is in usage, that is: at the
customer or, neing more general: at the user.
Murphy's Law. :)
> There are some standard C library
> functions, and many GTK+ stack functions, where passing a NULL pointer
> for a parameter is a documented fully normal way to specify some
> semantic variation of its API.
And the way it is handled is, to check against NULL,
because NULL is special.
>
>> And it's the only
>> exception that you have for your pointers,
>
> Well, as such some API could very well define some "well-known"
> special ("exceptional") pointer values and give them semantic meaning
> by themselves (i.e. the contents of what they point to would be
> irrelevant). That doesn't happen often, but it would be perfectly
> normal C.
>
> I mean something like:
>
> typedef struct FooBarStruct *FooBar;
>
> extern const FooBar FooBarMUMBLE;
> extern const FooBar FooBarPLUGH;
Yes, I like this idea.
it's not used often.
But it just adds more exceptional values to NULL.
And you only can detect them as exceptional, if you know
that definitions.
If you cast them to something else, you have problems to detect them.
But NULL is given from the language as really special value.
(And normally should be (void*) 0.).
The above idea is nice, and adds more of exceptional values,
but not as distinctionable as NULL.
Ciao,
Oliver
_______________________________________________
Gimp-developer mailing list
Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
