[C++ patch] accept __null as sentinel

[Joseph S. Myers]

On Sat, 30 Apr 2005, Michael Matz wrote:

> > And in the process of such copy&pasting, many casts would likely already 
> > have been added.
> 
> Are you guessing or knowing?  It's also done by looking at other source, 
> and doing only the difficult things in the same way.

I'm observing the conversion of a large body of source code - that of GCC 
- to be valid C++ as well as valid C.  A substantial part of the changes 
have been adding casts to deal with C++ being stricter.

> > So even if they think of NULL as a pointer it still needs the right
> > type.  It just so happens this isn't actually a case of C++ being
> > stricter than C, but one where it's easier to detect the problem with
> > the C++ compiler.
> 
> I agree partially.  But in this case I fail to see the problem which
> should be easier to detect.  It's a delimiter.  It has no type of it's
> own.  Hence no type is the inherently correct one (the _really_ correct
> one depends on the actual interface used, which might be completely
> opaque).  It just so happens, that _we_ require it be a pointer type

The correct type is that passed to va_arg (subject to very limited 
allowances, e.g. interchanging char* and void*); anything else yields 
undefined behavior.  The problem is unportability to any system where NULL 
is not passed compatibly with pointers (for example, one defining NULL to 
plain 0 even on 64-bit systems).

As a pragmatic matter, GCC uses a definition of NULL which makes 
unportable programs more likely to work by ensuring it is the same width 
as a pointer - and warns that the programs are unportable so the 
programmers can improve them.  This is a useful combination.  It has 
limitations; in particular if support is implemented for a system where 
the ABI for passing pointers and integers to variadic functions differs, 
then it won't work there for C++.  If we warned for such use of NULL for C 
as well, that would also be useful; we just aren't able to do so at 
present.  Adding a specific option to disable the warning would cater to 
users who aren't concerned with portability in this regard or to non-GCC 
systems while leaving the warning in -Wall as it meets the definition of 
-Wall ("all the warnings about constructions that some users consider 
questionable, and that are easy to avoid (or modify to prevent the 
warning), even in conjunction with macros").

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
    jsm@polyomino.org.uk (personal mail)
    joseph@codesourcery.com (CodeSourcery mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)