From: Linus Torvalds <torvalds@linux-foundation.org>
To: npiggin@suse.de, mingo@redhat.com, hpa@zytor.com,
linux-kernel@vger.kernel.org, jbeulich@novell.com,
a.p.zijlstra@chello.nl, JBeulich@novell.com, tglx@linutronix.de,
mingo@elte.hu
Subject: Re: [tip:core/locking] locking, x86: Slightly shorten __ticket_spin_trylock()
Date: Wed, 2 Dec 2009 07:26:35 -0800 (PST) [thread overview]
Message-ID: <alpine.LFD.2.00.0912020714420.2872@localhost.localdomain> (raw)
In-Reply-To: <tip-133ec7a235160dd44cbd4d82fff65a9983331df9@git.kernel.org>
On Wed, 2 Dec 2009, tip-bot for Jan Beulich wrote:
>
> locking, x86: Slightly shorten __ticket_spin_trylock()
NAK. This is horrible crap. Don't ever send me this kind of broken patch
again.
> - int new;
> + union { int i; bool b; } new;
No thank you. This is total bogosity.
You have zero idea what type "bool" is, do you? It can well be "int", it
can be "char", it can be some compiler-internal type ("_Bool"). You have
no idea what size it is.
And maybe it _is_ just a byte. But even if it is, using 'bool' here is
wrong. The fact is, bool has magic semantic properties outside of sizing.
You can't mix it with inline asm, because you simply don't know what the
compiler rules for 'bool' are.
For example, maybe the rules are that it's always passed as an integer,
and is always guaranteed to have the values 0/1. So even if 'sizeof'
returns 1, that doesn't actually mean that you can necessarily pass it
around as a char - it only means that it will take one byte in a structure
(except that bool arrays might be packed, I think).
In other words, the semantics of 'bool' are such that you have no clue
what the actual ABI for 'bool' is. You cannot mix this with asm.
Secondly, the notion of using a union here is just totally broken. There's
no point to it, and it just makes the code look horrible.
So if you want to do this, then just keep 'new' as an int, and make sure
that the function returns a 'char'. No games with 'bool' which is badly
defined, no games with unions.
And please do make sure that it actually doesn't deprove code at the
callers too.
Linus
next prev parent reply other threads:[~2009-12-02 15:27 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-27 15:09 [PATCH] x86: slightly " Jan Beulich
2009-12-02 10:45 ` [tip:core/locking] locking, x86: Slightly " tip-bot for Jan Beulich
2009-12-02 13:29 ` Ingo Molnar
2009-12-02 14:06 ` Jan Beulich
2009-12-02 14:12 ` Avi Kivity
2009-12-02 14:25 ` Jan Beulich
2009-12-02 14:36 ` Avi Kivity
2009-12-02 14:59 ` Jan Beulich
2009-12-02 14:21 ` Ingo Molnar
2009-12-02 14:57 ` Jan Beulich
2009-12-02 15:33 ` Linus Torvalds
2009-12-02 15:26 ` Linus Torvalds [this message]
2009-12-02 16:24 ` Jan Beulich
2009-12-02 16:56 ` Linus Torvalds
2009-12-02 17:05 ` Linus Torvalds
2009-12-02 17:23 ` H. Peter Anvin
2009-12-02 17:48 ` Linus Torvalds
2009-12-02 17:58 ` H. Peter Anvin
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=alpine.LFD.2.00.0912020714420.2872@localhost.localdomain \
--to=torvalds@linux-foundation.org \
--cc=a.p.zijlstra@chello.nl \
--cc=hpa@zytor.com \
--cc=jbeulich@novell.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=mingo@redhat.com \
--cc=npiggin@suse.de \
--cc=tglx@linutronix.de \
/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
Powered by JetHome