From: Al Viro <viro@ftp.linux.org.uk>
To: Josh Triplett <josh@freedesktop.org>
Cc: linux-sparse@vger.kernel.org,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: fun with ?:
Date: Wed, 23 May 2007 01:25:06 +0100 [thread overview]
Message-ID: <20070523002506.GK4095@ftp.linux.org.uk> (raw)
In-Reply-To: <20070523000234.GJ4095@ftp.linux.org.uk>
On Wed, May 23, 2007 at 01:02:34AM +0100, Al Viro wrote:
> Moral: void * -> int * may lose parts of value and trigger undefined behaviour;
> int * -> void * loses information about type, is always revertible and always
> safe. In assignment operator it's your responsibility to make sure that
> void * you are converting to int * is properly aligned (anything that started
> its life as int * will be). In ?: C could
> * lose type information, allowing any values (result is void *); if
> you are sure that it's well-aligned, you can cast void * argument to int *
> or cast the result.
> * require the void * argument to be well-aligned, keep the type.
>
> The former makes more sense...
PS: that's a design decision that had to be made back when void * got added
to the language and it had to work for all architectures. IOW, the text
above is explanation why it had to be done that way and why we have to
stick to it on all targets.
> > I see. I find it very strange that (void *)0 and (void *)(void *)0 have
> > different behavior. I also find it strange that conditional expressions can't
> > convert void * to an arbitrary pointer as assignment can.
>
> It would be nicer if C had __null__ as the *only* null pointer constant
> (with flexible type) and could refuse to accept anything else. Too late
> for that, unfortunately. As for conversions - see above.
To clarify: all mess with null pointer constants comes from lack of
explicit token and need to avoid massive breakage of old programs. That's
what it's all about - compiler recognizing some subexpressions as
representations of that missing token and trying to do that in a way that
would break as little as possible of existing C code. It's an old story -
decisions had to be made in 80s and now we are stuck with them.
IOW, (void *)0 in contexts that allow null pointer constant is *not* a
0 cast to pointer to void; it's a compiler-recognized kludge for __null__.
And it's not a pointer to void. It can become a pointer to any type,
including void. If converted to a pointer type it gives the same value
you get if you convert 0 to that type ("null pointer to type"). But
unlike null pointer to type it retains full flexibility.
NULL is required to expand to null pointer constant and that's one of
the reasons why sane code should be using it instead of explicitly spelled
variants. The next best thing to actually having __null__ in the language...
next prev parent reply other threads:[~2007-05-23 0:25 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-19 2:52 fun with ?: Al Viro
2007-05-22 21:40 ` 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 [this message]
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=20070523002506.GK4095@ftp.linux.org.uk \
--to=viro@ftp.linux.org.uk \
--cc=josh@freedesktop.org \
--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 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).