bug-gnulib
[Top][All Lists]
Advanced

[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).


Attachment: uu
Description: Text Data


reply via email to

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