> 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@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer