From: Al Viro <viro@ftp.linux.org.uk>
To: linux-sparse@vger.kernel.org
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Subject: fun with ?:
Date: Sat, 19 May 2007 03:52:49 +0100 [thread overview]
Message-ID: <20070519025249.GZ4095@ftp.linux.org.uk> (raw)
There's an unpleasant case in conditional operator we are getting
wrong.
int *p;
const void *v;
int n;
n ? p : (const void *)0
According to C standard, the type of that expression is const void *. Note
that
n ? p : (void *)0
is an entirely different story - it's int *.
What's going on here is pretty simple: there are two degenerate cases of
conditional operator: pointer vs. null pointer constant and pointer vs.
possibly qualified pointer to void. Look at these cases:
n ? p : NULL => should be the same type as p
n ? p : v => clearly const void * - pointer to void with union of
qualifiers; in this case we obviously lose any information about the type
of object being pointed to.
The tricky part comes from definition of what null pointer constant _is_.
C allows two variants - integer constant expression with value 0 (we accept
it, but warn about bad taste) and the same cast to void * (we also accept
that, of course).
Note that this is specific type - pointer to void. Without any qualifiers.
We are guaranteed that we can convert it to any pointer type and get
a pointer distinct from address of any object. So (const void *)0 is the same
thing as (const void *)(void *)0 and it is the null pointer to const void.
*HOWEVER*, it is not a null pointer constant. The standard is clear here and
frankly, it's reasonable. If you cast to anything other than void *, then
you presumably mean it and want the conversion rules as for any pointer
of that type. Think of something like
#ifdef FOO
const void *f(int n);
#else
#define f(n) ((const void *)NULL)
#endif
You don't want to have types suddenly change under you depending on FOO.
sparse is more liberal than standard C in what it accepts as null pointer
constant. It almost never matters; however, in case of conditional operator
we end up with a different type for an expression both sparse and any
C compiler will accept as valid.
I'm fixing other fun stuff in that area (e.g. we ought to take a union of
qualifiers, ought _not_ to mix different structs or unions, etc.), so
unless there are serious objections I'd rather go with standard behaviour
in that case. What will change:
int n;
int *p;
n ? p : (const void *)NULL int * => const void *
n ? p : (const void *)0 ditto
n ? p : (char *)0 int * => a warning on mixing int * with char *
n ? p : (char *)NULL ditto
n ? p : (void *)NULL int * => void *
n ? p : (void *)0 unchanged
n ? p : NULL unchanged
Objections?
next reply other threads:[~2007-05-19 2:52 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-19 2:52 Al Viro [this message]
2007-05-22 21:40 ` fun with ?: Josh Triplett
2007-05-22 22:46 ` Al Viro
2007-05-22 23:24 ` Josh Triplett
2007-05-23 0:02 ` Al Viro
2007-05-23 0:25 ` Al Viro
2007-05-23 1:05 ` Josh Triplett
2007-05-23 4:53 ` Al Viro
2007-05-23 12:26 ` Morten Welinder
2007-05-23 1:03 ` Josh Triplett
2007-06-03 1:05 ` Al Viro
2007-05-23 14:25 ` Neil Booth
2007-05-23 14:32 ` Al Viro
2007-05-23 14:47 ` Neil Booth
2007-05-23 15:32 ` Al Viro
2007-05-23 23:01 ` Neil Booth
2007-05-24 0:10 ` Derek M Jones
2007-05-24 0:14 ` Al Viro
2007-05-23 21:16 ` Derek M Jones
2007-05-23 21:59 ` Linus Torvalds
2007-05-23 23:29 ` Derek M Jones
2007-05-24 0:02 ` Al Viro
2007-05-24 0:29 ` Linus Torvalds
2007-05-24 1:36 ` Brett Nash
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=20070519025249.GZ4095@ftp.linux.org.uk \
--to=viro@ftp.linux.org.uk \
--cc=linux-sparse@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.