[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130112133114.GH20323@brightrain.aerifal.cx>
Date: Sat, 12 Jan 2013 08:31:14 -0500
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: NULL
On Sat, Jan 12, 2013 at 12:56:08AM -0600, Rob Landley wrote:
> >The original reason I left NULL with pointer type was to catch the
> >other idiotic error:
> >
> > str[len]=NULL;
> >
> >i.e. confusion of NULL with ASCII NUL.
>
> They're both 0. If the optimizer can't convert the type down when
> handed a constant assignment, the optimizer should be shot.
No. ASCII nul is an integer 0. NULL is a null pointer constant, which
may be an integer constant expression 0 or may be (void *)0. This has
nothing to do with the optimizer and everything to do with constraint
violations. The error was mainly made by C++ programmers (or C
programmers wrongly compiling their programs with C++ compilers...) on
implementations that used 0 as the definition of NULL; when compiled
on most proper C implementations, the code yields an error, because
assignment of a pointer to an integer is a constraint violation. (On
gcc, it's just a warning by default.)
I don't think there's a lot of value in catching this error anymore.
> >However, this raises a good
> >question: short of C11 _Generic, is it even possible for a program to
> >detect whether NULL has integer or pointer type?
>
> The C99 standard says that NULL has pointer type. Thus when you pass
No it does not. We have addressed this multiple times already.
> it in varargs, it should be a long on any LP64 system which is
> basically "everything but windows" for about 20 years now.
Actually the type doesn't matter to correct programs. The question is
whether we want to coddle incorrect programs, and the answer folks
seem to be leaning towards is yes, in which case 0L would be the right
definition to accomplish this.
> >I know of one way, but it's very obscure:
>
> You can do sizeof(NULL) and (char *)(NULL+1)-(char *)(NULL) to get
> the size of the type it points to?
NULL+1 is a constraint violation if NULL has pointer type (since the
only pointer type it's permitted to have is void *).
> Not sure what question you're asking...
>
> >int null_is_ptr_type()
> >{
> > char s[1][1+(int)NULL];
> > int i = 0;
> > return sizeof s[i++], i;
> >}
>
> (int)NULL is 0 according to C99 so the NULL in there has no effect.
It does. (int)0 is an integer constant expression. (int)(void *)0
happens to be semantically constant, but it's not an integer constant
expression. Therefore, depending on the definition of NULL, s may be a
regular array type or a variable-length array type. In the latter
case, s[i++] has VLA type and thus sizeof is required to evaluate its
argument. GCC versions prior to 4.5 were buggy in this regard.
> And referring to "i++" and "i" in the same statement is explicitly
> undefined behavior (comma is not a sequence point, the compiler is
Comma is a sequence point.
> free to evaluate those in any order and different optimization flags
> _will_ change that order; I got bit by that many moons ago).
No, you were doing something else wrong. To my knowledge there has
never been a compiler that did not honor the comma operator sequence
point, certainly not any GCC or clang.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
