[Top][All Lists]
[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-----