Re: NULL

[Rob Landley <rob@landley.net>]

On 01/09/2013 09:36:30 AM, Rich Felker wrote:
> On Wed, Jan 09, 2013 at 04:18:12PM +0100, John Spencer wrote:
> > >__attribute__ ((sentinel)) may be used. Adding this to the  
> appropriate
> > >gtk headers (even just as a temporary debugging measure if it's not
> > >desirable permanently) would catch all the bugs calling gtk  
> variadic
> > >functions.
> > >
> >
> > indeed this does emit a warning. however, it will only detect
> > sentinels, not other variadic arguments that are expected to be
> > pointers but will be passed as int instead. i haven't tested, but it
> > will most likely also cause crashes.
> 
> Indeed, you are correct. I suspect most such uses _also_ have a
> sentinel where incorrect code will also mess up the sentinel, but in
> principle it's possible that this does not happen.
> 
> A good system of static analysis for variadic functions would need
> some way to express the interface contract in terms of a predicate on
> the argument types (and possibly contents) of arguments. I'm not aware
> of any such system existing, so the matter falls back to whether we
> would really need it to avoid all these bugs.

You mean like "__attribute__ ((__format__ (__printf__, 2, 3)));"?

This is the job of lint's descendents (ala the stanford checker or  
sparse). This is really not the compiler's job. (The printf checking is  
bad enough and it's hardwiring in constraints expressed in the C  
standard. If you write your own function that's implementing its own  
rules, the compiler has no idea what you did. Working _out_ what you  
did equals solving the halting problem.)

> > >If we decide something is needed at the musl level, in my opinion  
> the
> > >only acceptable solution is just replacing 0 with 0L  
> unconditionally.
> > >Actually I'd like to remove the special-case for C++ and make NULL
> > >_always_ be defined to 0 or 0L, but I worry too many people would
> > >complain...
> >
> > yes, 0L is definitely nicer.
> > regarding C code, it would infact be more consequent if you make it
> > 0/0L there as well.
> > what issues could arise in C code when (void* ) 0 is replaced with  
> 0L ?
> 
> 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.

(That said, I use 0 in my code instead of NUL or '\0' because 0 is 0.)

> 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 it  
in varargs, it should be a long on any LP64 system which is basically  
"everything but windows" for about 20 years now.

> 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?

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. And  
referring to "i++" and "i" in the same statement is explicitly  
undefined behavior (comma is not a sequence point, the compiler is free  
to evaluate those in any order and different optimization flags _will_  
change that order; I got bit by that many moons ago).

Rob