This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [C++ patch] accept __null as sentinel
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)