From: Josh Triplett <josh@freedesktop.org>
To: Al Viro <viro@ftp.linux.org.uk>
Cc: linux-sparse@vger.kernel.org,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: fun with ?:
Date: Tue, 22 May 2007 18:05:39 -0700 [thread overview]
Message-ID: <46539363.3010202@freedesktop.org> (raw)
In-Reply-To: <20070523002506.GK4095@ftp.linux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1492 bytes --]
Al Viro wrote:
> On Wed, May 23, 2007 at 01:02:34AM +0100, Al Viro wrote:
>> 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...
That makes perfect sense now. Thanks for the explanation.
- Josh Triplett
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
next prev parent reply other threads:[~2007-05-23 1:06 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
2007-05-23 1:05 ` Josh Triplett [this message]
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=46539363.3010202@freedesktop.org \
--to=josh@freedesktop.org \
--cc=linux-sparse@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=viro@ftp.linux.org.uk \
/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).