linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: "Theodore Ts'o" <tytso@mit.edu>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	David Laight <David.Laight@aculab.com>,
	Ingo Molnar <mingo@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	David Miller <davem@davemloft.net>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"the arch/x86 maintainers" <x86@kernel.org>,
	Network Development <netdev@vger.kernel.org>,
	"linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>
Subject: Re: Unsigned widening casts of binary "not" operations..
Date: Tue, 23 Apr 2013 09:05:24 -0700	[thread overview]
Message-ID: <CA+55aFwmgotLczo56Xu1eSvLogR9hRwU4ts3B2oAkOUfYMkNuw@mail.gmail.com> (raw)
In-Reply-To: <20130423155212.GI31170@thunk.org>

On Tue, Apr 23, 2013 at 8:52 AM, Theodore Ts'o <tytso@mit.edu> wrote:
>
> Maybe it's worth creating a magic helper function, called something
> like mask_out() that handles the casting automatically, and it makes
> it clear to a reader what you're trying to do?

We have that for some things. Like the aligning code (see
include/{uapi/}linux/kernel.h). We have that whole ALIGN()
infrastructure that casts the alignment to the result type, exactly
because people got things wrong so often (and exactly the "& ~mask"
thing in particular).

But doing so becomes *less* readable when the types already match, and
it's another extra complication in kernel programming to know all the
"oh, don't use the standard C &~ constructs because it has some subtle
type handling under *some* circumstances". So for aligning things up,
we've been able to do it, because people hate doing that duplicated "
(val + mask) & ~mask" thing anyway (especially since "mask" tends to
be something like "size-1". IOW, having a helper function/macro ends
up solving more than just the type issue. But if it's just the type,
it ends up being very inconvenient.

We don't have the equivalent "align down" macro, for example, exactly
because aligning things down is *just* the logical mask, and so in
most cases it's actually just more pain to have a macro helper. So
ALIGN() only aligns upwards, even though it doesn't even say so in the
name. Inconsistent? Unclear? Yes, but there's a reason for it.

                  Linus

  reply	other threads:[~2013-04-23 16:05 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CA+55aFwpLu0qNms=hkQr43yqD0K9DgESNm91OEWKT1ZuT8MU6Q@mail.gmail.com>
2013-04-23  0:23 ` Unsigned widening casts of binary "not" operations Linus Torvalds
2013-04-23  8:59   ` David Laight
2013-04-23 14:29     ` Linus Torvalds
2013-04-23 15:24       ` David Laight
2013-04-23 15:42         ` Linus Torvalds
2013-04-23 15:52           ` Theodore Ts'o
2013-04-23 16:05             ` Linus Torvalds [this message]
2013-04-23 17:37           ` David Miller
2013-04-23 17:52             ` Linus Torvalds
2013-04-23 17:56               ` David Miller
2013-04-23 18:21                 ` Linus Torvalds
2013-04-24 12:36             ` Geert Uytterhoeven
2013-04-23  0:32 ` H. Peter Anvin
2013-04-23 13:00 ` Theodore Ts'o
2013-04-24  7:26 ` Ingo Molnar
2013-04-24  7:47   ` Cyrill Gorcunov
2013-04-25  1:13     ` Lin Ming
2013-04-24 17:07   ` [PATCH] x86: make DR*_RESERVED unsigned long Oleg Nesterov
2013-04-24 18:45     ` H. Peter Anvin
2013-04-25 14:48       ` Oleg Nesterov
2013-04-26 16:38         ` [PATCH v2] " Oleg Nesterov
2013-04-26 16:44           ` H. Peter Anvin
2013-04-26 17:15             ` Oleg Nesterov
2013-04-27 14:45               ` Oleg Nesterov
2013-04-27 16:20                 ` H. Peter Anvin
2013-04-28  0:58                 ` Frederic Weisbecker
2013-04-28 17:27                   ` Oleg Nesterov
2013-04-28 17:32                     ` H. Peter Anvin
2013-04-28 17:39                       ` Oleg Nesterov
2013-04-28 17:43                         ` H. Peter Anvin
2013-04-24 22:48     ` [PATCH] " Frederic Weisbecker
2013-04-24 23:06       ` H. Peter Anvin
2013-04-24 23:31         ` Frederic Weisbecker
2013-04-25  1:20           ` 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=CA+55aFwmgotLczo56Xu1eSvLogR9hRwU4ts3B2oAkOUfYMkNuw@mail.gmail.com \
    --to=torvalds@linux-foundation.org \
    --cc=David.Laight@aculab.com \
    --cc=davem@davemloft.net \
    --cc=hpa@zytor.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=tytso@mit.edu \
    --cc=x86@kernel.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).