Re: [PATCH] Trivial warning fix for imap-send.c

[Linus Torvalds <torvalds@osdl.org>]

On Sun, 12 Mar 2006, Mark Wooding wrote:
> "Art Haas" <ahaas@airmail.net> 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