[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: definition of NULL
From: |
Bruno Haible |
Subject: |
Re: definition of NULL |
Date: |
Thu, 13 Aug 2009 11:41:14 +0200 |
User-agent: |
KMail/1.9.9 |
Hi Eric,
Wow! What a large change.
> There are only 7 headers defined by POSIX to
> define NULL, and we already provide gnulib overrides for 6 of the 7 (the only
> one lacking was stddef.h itself).
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.
> Here's what I'm testing
I got some "malformed patch" errors while applying the patch. Due to wrapped
lines such as
@@ -12,6 +12,11 @@ The macros @code{EXIT_SUCCESS} and @code{EXIT_FAILURE} are
not defined on
Can you produce your patches without the diff -p option, or attach them
rather than include them in the mail?
> This patch does not do anything about the *printf family basing a lot of code
> on HAVE_WCHAR_T; one idea is that we could make the *printf-posix versions of
> these macros require the stddef module and then blindly assume that wchar_t
> is
> available (although this means updating several #if checks), while leaving
> the
> simpler *printf versions at the mercy of the platform's (lack of) wchar_t.
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.
> For that matter, I couldn't find any definitive documentation of a modern
> platform
> that lacks wchar_t (just that some uclibc builds lack <wchar.h>).
But the uClibc users are stubborn in their refusal to use wchar_t in some
builds.
> Any other comments, while I continue with my testing?
In unistd.in.h:32 I would change the comment
/* NetBSD 5.0 mis-defines NULL. */
to
/* NetBSD 5.0 mis-defines NULL. Also get size_t. */
In m4/locale_h.m4 it's a waste of configure time to check for the include_next
support of locale.h if it's not going to be replaced. I would keep doing
gl_CHECK_NEXT_HEADERS([locale.h])
conditionally.
Likewise for m4/stddef_h.m4 and m4/wchar.m4.
In m4/stddef_h.m4, I would not use a conditional expression inside an array
subscript. C requires an array subscript to be an integer constant
expression, but some older C standard did not mention that conditional
expressions consisting of integer constant expressions are integer constant
expressions. Therefore it's safer only to play with + - * /.
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."
A test case is
============================= foo.cc ============================
#include <stddef.h>
struct A {
int foo (void *);
int foo (char *);
int foo (int);
int foo (long);
};
int A::foo (void *) { return 1; }
int A::foo (char *) { return 2; }
int A::foo (int) { return 0; }
int A::foo (long) { return 0; }
int verify_size[2 * (sizeof NULL == sizeof (void *)) - 1];
int main ()
{
A x;
return x.foo(NULL);
}
// g++ 3.1...4.3.3 all call A::foo (int).
// The openSUSE g++ 4.3.1 calls A::foo (long).
==================================================================
Find attached the changes that I would apply on top of yours (to be
applied with "patch -p0", as always).
uu
Description: Text Data