> 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?
> The same is here: a NULL-pointer is an exception.
Only if you try to dereference it. 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 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;
where the actual contents of the structs pointed to by FooBarMUMBLE
and FooBarPLUGH would have no meaning, the only meaning would be that
if for some function a FooBar argument equals FooBarMUMBLE it would
have a special meaning (and the pointer would not be dereferenced),
and ditto for FooBarPLUGH.
--tml
_______________________________________________
Gimp-developer mailing list
Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
