[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1357973768.32505.5@driftwood>
Date: Sat, 12 Jan 2013 00:56:08 -0600
From: Rob Landley <rob@...dley.net>
To: musl@...ts.openwall.com
Cc: musl@...ts.openwall.com
Subject: Re: NULL
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
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.
