mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@aerifal.cx>
To: musl@lists.openwall.com
Subject: Re: NULL
Date: Wed, 9 Jan 2013 10:36:30 -0500	[thread overview]
Message-ID: <20130109153630.GZ20323@brightrain.aerifal.cx> (raw)
In-Reply-To: <50ED8A34.5070904@barfooze.de>

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.

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

I know of one way, but it's very obscure:

int null_is_ptr_type()
{
	char s[1][1+(int)NULL];
	int i = 0;
	return sizeof s[i++], i;
}

Are there any ways that might actually affect/break programs?

Rich


  reply	other threads:[~2013-01-09 15:36 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-09 11:02 NULL John Spencer
2013-01-09 12:18 ` NULL Szabolcs Nagy
2013-01-09 13:36   ` NULL John Spencer
2013-01-12  6:32     ` NULL Rob Landley
2013-01-12  6:46       ` NULL Rich Felker
2013-01-12  7:15         ` NULL Luca Barbato
2013-01-12 13:33           ` NULL Rich Felker
2013-01-12 11:39       ` NULL Jens Staal
2013-01-09 13:09 ` NULL croco
2013-01-09 13:47   ` NULL John Spencer
2013-01-09 14:49     ` NULL croco
2013-01-09 14:42 ` NULL Luca Barbato
2013-01-09 14:47   ` NULL Rich Felker
2013-01-09 15:03     ` NULL Luca Barbato
2013-01-09 15:18     ` NULL John Spencer
2013-01-09 15:36       ` Rich Felker [this message]
2013-01-09 21:11         ` NULL Rob
2013-01-09 21:53           ` NULL Szabolcs Nagy
2013-01-09 22:17             ` NULL Rob
2013-01-09 23:42         ` NULL Szabolcs Nagy
2013-01-12  6:56         ` NULL Rob Landley
2013-01-12  7:07           ` NULL Bobby Bingham
2013-01-12 13:31           ` NULL Rich Felker
2013-01-13 14:29             ` NULL Rob Landley
2013-01-13 14:56               ` NULL Luca Barbato
2013-01-13 16:29                 ` NULL Rob Landley
2013-01-13 17:14                   ` NULL Luca Barbato
2013-01-13 15:23               ` NULL Strake
2013-01-13 17:17                 ` NULL Luca Barbato
2013-01-13 17:47               ` NULL Szabolcs Nagy
2013-01-13 19:46                 ` NULL Rob Landley
2013-01-14  6:11                   ` NULL Rich Felker
2013-01-14  8:45                     ` musl as a framework to test applications' compatibility with POSIX (was: NULL) Vasily Kulikov
2013-01-14 14:03                       ` Rich Felker
2013-01-14 14:30                         ` Vasily Kulikov
2013-01-14 15:02                           ` Szabolcs Nagy
2013-01-14 15:14                           ` Rich Felker
2013-01-14 13:19                     ` NULL Rob Landley
2013-01-12  5:56 ` NULL Rob Landley
2013-01-12  6:42   ` NULL Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130109153630.GZ20323@brightrain.aerifal.cx \
    --to=dalias@aerifal.cx \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).