bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: definition of NULL


From: Eric Blake
Subject: Re: definition of NULL
Date: Thu, 13 Aug 2009 07:04:36 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.6.666

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Bruno Haible on 8/13/2009 3:41 AM:
> Hi Eric,
> 
> Wow! What a large change.

Largely repetitive, but it adds up fast!

> You handled locale.h, stddef.h, stdio.h, stdlib.h, string.h, unistd.h, 
> wchar.h,
> but time.h also should define NULL, according to POSIX.

Oh, good point.  I've included <time.h> in the patch refresh.

> I got some "malformed patch" errors while applying the patch. Due to wrapped
> lines

I hate gmane's patch mangling, with no option for patch attachments.
Updated patches are available here, with your changes squashed in:

$ git pull git://repo.or.cz/gnulib/ericb.git master

I still need time to test on my NetBSD access point.

> The vasnprintf code is also shared with libintl, which does not use any
> replacements of <locale.h>, <stdlib.h>, nor <stddef.h>. Therefore defining
> wchar_t for all platforms, while possible, would not simplify vasnprintf.

I agree that because of libintl, it would not reduce the amount of #ifdef,
but it could at least let us support wchar_t in the -posix variants.  But
that's for another day.  And my question still remains - are there any
modern platforms that flat out lack the wchar_t type in <stddef.h>,
regardless of whether <wchar.h> is supported?

> 
> The replacement value that you are using for NULL is not right for C++. In
> ISO C++ <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1905.pdf>
> sections 18.1.(3) and footnote 188 say
>   "The macro NULL is an implementation-defined C++ null pointer constant in
>    this International Standard (4.10).
>    Possible definitions include 0 and 0L, but not (void*)0."

IIUC, the draft version of C++0x is introducing __nullptr as a version of
NULL that can't be confused with an integer context.  So using 0 is
correct for the current C++ standard, but not future-proof.

> // g++ 3.1...4.3.3 all call A::foo (int).
> // The openSUSE g++ 4.3.1 calls A::foo (long).

Once the new C++ standard is out with its improved rules for NULL, a
conformant compiler should call A::foo (void *) (or maybe it will fail
with a complaint that the overload resolution between void* and char* is
ambiguous; I'd have to reread the proposed spec to be sure).  But I'm less
worried about fixing that now (as you mentioned, the patch is already
big), so I just went with your patch as-is.

Besides, NetBSD's bug with under-parenthesized NULL appears to be C only;
their C++ definition looks correct - from the /usr/include/sys/null.h of
the NetBSD 1.6 machine that I have access to, I see:

#ifndef NULL
#if !defined(__GNUG__) || __GNUG__ < 2 || (__GNUG__ == 2 && __GNUC_MINOR__
< 90)
#if defined(__AUDIT__) && !defined(__cplusplus)
/*
 * This will cause GCC to emit a warning if you attempt to use NULL
 * with some non-pointer object, return value, etc.
 */
#define NULL    (void *)0
#else
#define NULL    0
#endif /* __AUDIT__ && !__cplusplus */
#else
#define NULL    __null
#endif


- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkqED2QACgkQ84KuGfSFAYASsACeKKs334+OAg9ph1QFLHgSUWz9
pXwAoLH5UiXh7eyJ96aTbfNJVZEDcOVa
=Nxr5
-----END PGP SIGNATURE-----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]