Since this is not about any particular patch to findutils I have moved the discussion.
http://lists.gnu.org/archive/html/findutils-patches/2007-06/msg00034.html Eric Blake-1 wrote: > But that is bug-prone. > > Consider: > > printf("%p%d", NULL, 1); > vs. > printf("%p%d", 0, 1); You make a compelling argument for that case. Because gcc is capable of checking format strings it can use this to detect this case. However %p has never produced portable results for me and so I would never use it in that context and also I don't see the value in printing as a %p either NULL or 0 immediate value and so this is rather contrived. Can you produce a more typical case? The following is more typical. void *var1 = 0; void *var2 = NULL; printf("%p\n", var1); printf("%p\n", var2); In this case neither gcc nor g++ -O -Wall flag any errors or differences. Here is another example. typedef struct var { int value; } var_t; var_t *var1 = 0; if (var1) { printf ("%d\n", var1->value); } if (var1 != 0) { printf ("%d\n", var1->value); } if (var1 != NULL) { printf ("%d\n", var1->value); } Of these I prefer '(var1 != 0)' but also have used the simple '(var1)' with its implied '!= 0' often enough too. But in the uses I normally see for NULL such as the above it does not provide additional type checking. I welcome counter examples. I am always happy to use NULL when the function argument type requires it and no prototypes are in scope. Such as in K&R C without prototypes the use of setvbuf, strtok, select, others require a pointer type argument. But I am always happier to use C with prototypes in scope. I don't like casts in source code and even though NULL hides/obfuscates the type cast in C it annoys me to have the cast there just the same. > On a 32-bit platform, it works. On a 64-bit platform, it fails. Your example behaves identically for me on my 64-bit and 32-bit platforms. But I don't think that is important to this discussion. > Using NULL consistently prevents bugs like this, because > unlike 0, the named constant NULL also conveys type > information. Yes, 'gcc -Wall' will tell you about this > particular example, but I find it easier to use a named > constant than to risk this type of bug. Regardless, I still prefer it just the same. It is the C++ programmer in me showing through. I will have to work on keeping that part in check. :-) > Another reason to prefer NULL when a pointer is intended > is due to function overloading in C++, where foo(0) and > foo(NULL) could invoke different code paths. C++ is not C and the type rules are quite different there. In C++ void* cannot be automatically coerced into pointers of different types therefore NULL cannot be defined as (void*)0. Typically in C++ NULL is defined to be 0. Outside of g++ in other C++ compilers NULL really is the same as 0. g++ uses an internal extension __null to provide for additional type checking but most other compilers do not. BTW... I don't feel the need to try to convince anyone. If I did then we would have to move on to the one true brace style or more significantly whether the return from malloc() should be cast (the return of malloc() should never be cast in C) and so forth. :-) Bob _______________________________________________ Bug-findutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-findutils
