From: Linus Torvalds <torvalds@osdl.org>
To: Mark Wooding <mdw@distorted.org.uk>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] Trivial warning fix for imap-send.c
Date: Sun, 12 Mar 2006 15:02:40 -0800 (PST) [thread overview]
Message-ID: <Pine.LNX.4.64.0603121457520.3618@g5.osdl.org> (raw)
In-Reply-To: <slrne18of5.fr9.mdw@metalzone.distorted.org.uk>
On Sun, 12 Mar 2006, Mark Wooding wrote:
> Linus Torvalds <torvalds@osdl.org> wrote:
>
> > So in modern C, using NULL at the end of a varargs array as a pointer is
> > perfectly sane, and the extra cast is just ugly and bowing to bad
> > programming practices and makes no sense to anybody who never saw the
> > horror that is K&R.
>
> No! You can still get bitten. You're lucky that on common platforms
> all pointers look the same, but if you find one where `char *' (and
> hence `void *') isn't the same as `struct foo *' then, under appropriate
> circumstances you /will/ unless you put the casts in.
Not relevant. Show me any system that matters.
The fact is, compilers should conform to programmers, not the other way
around. Bending over backwards for broken systems is _wrong_. The fact
that there are insane build environments doesn't excuse bad manners, and
explicit casts that aren't needed are HORRIBLE manners.
There is no valid reason to _ever_ cast NULL pointers.
Btw, the same goes for casting the result from malloc etc, which some
people also do.
Put another way: you should not encourage insane systems, and you should
definitely NOT encourage nit-picking people who read the standards in
insane ways and say that the standards _allow_ badly behaved build
environments.
It's true that the standards _allow_ crazy build environments. Who the
f*ck cares? Crazy and bad build environments aren't any better for being
allowed by the standard. Screw them. Call them names. And refuse to work
with them.
Linus
prev parent reply other threads:[~2006-03-12 23:02 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-11 19:29 [PATCH] Trivial warning fix for imap-send.c Art Haas
2006-03-12 10:44 ` Mark Wooding
2006-03-12 11:27 ` Junio C Hamano
2006-03-12 13:59 ` [PATCH] Use explicit pointers for execl...() sentinels Mark Wooding
2006-03-12 15:13 ` Timo Hirvonen
2006-03-12 17:32 ` Mark Wooding
2006-03-12 18:08 ` Timo Hirvonen
2006-03-13 3:31 ` Jeff King
2006-03-13 4:12 ` Horst von Brand
2006-03-14 0:42 ` [OT] " Jeff King
2006-03-12 16:57 ` [PATCH] Trivial warning fix for imap-send.c Linus Torvalds
2006-03-12 18:01 ` Mark Wooding
2006-03-12 19:20 ` A Large Angry SCM
2006-03-13 2:59 ` H. Peter Anvin
2006-03-13 4:36 ` A Large Angry SCM
2006-03-13 5:22 ` Linus Torvalds
2006-03-13 6:37 ` H. Peter Anvin
2006-03-13 6:46 ` Linus Torvalds
2006-03-13 16:37 ` Olivier Galibert
2006-03-13 3:38 ` Jeff King
2006-03-13 4:14 ` Horst von Brand
2006-03-13 16:26 ` Linus Torvalds
2006-03-13 6:41 ` H. Peter Anvin
2006-03-12 21:51 ` Horst von Brand
2006-03-12 23:02 ` Linus Torvalds [this message]
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=Pine.LNX.4.64.0603121457520.3618@g5.osdl.org \
--to=torvalds@osdl.org \
--cc=git@vger.kernel.org \
--cc=mdw@distorted.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).