On Sun, 12 Mar 2006, Mark Wooding wrote:
> "Art Haas" <ahaas@xxxxxxxxxxx> wrote:
>
> > - execl( "/bin/sh", "sh", "-c", srvc->tunnel, 0 );
> > + execl( "/bin/sh", "sh", "-c", srvc->tunnel, NULL );
>
> This is not the right fix. NULL can be simply a #define for 0 (see
> 6.3.2.3#3 and 7.17). You need to write (char *)0 or (char *)NULL. I
> prefer to avoid the macro NULL entirely, since its misleading behaviour
> is precisely what got us into this mess.
It's perfectly fine.
Quite frankly, if you have a 64-bit C compiler that doesn't make "NULL" be
"((void *)0)" (or equivalent - some compilers will actually have NULL as
an intrisic, because especially if they also support C++, NULL has some
really magical properties there), you should switch vendors as quickly as
humanly possible.
The "#define NULL 0" practice is still _legal_ C, but that doesn't make it
any less broken. It's K&R traditional, but git requires ANSI prototypes
and some fancy features from modern compilers, so K&R compilers aren't
welcome anyway, and if their headers don't define NULL as a void pointer,
their headers are simply _broken_.
So in modern C, using NULL at the end of a varargs array as a pointer is
perfectly sane, and the extra cast is just ugly and bowing to bad
programming practices and makes no sense to anybody who never saw the
horror that is K&R.
It's akin to trying to not using prototypes, or to trying to limit your
externally visible names to 7 characters. It was "appropriate" about two
decades ago, these days it's just cuddling broken setups that have been
broken for a long long time.
Btw, the reason NULL _has_ to be a pointer ("((void *)0)" or otherwise) is
simply that if it isn't, you not only won't get reasonable varargs
behaviour, you'll also miss real warnings. I've seen broken code like
int i = NULL;
in my life, and if the compiler doesn't warn about that, then the compiler
is BROKEN, and not worth supporting as a programmer.
Linus
-
: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html