From: Linus Torvalds <torvalds@linux-foundation.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>,
Konstantin Khlebnikov <khlebnikov@openvz.org>,
Minchan Kim <minchan@kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Hugh Dickins <hughd@google.com>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Ben Herrenschmidt <benh@kernel.crashing.org>,
"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>
Subject: Re: [PATCH 00/16] mm: prepare for converting vm->vm_flags to 64-bit
Date: Thu, 22 Mar 2012 15:08:43 -0700 [thread overview]
Message-ID: <CA+55aFzbhYvw7Am9EYgatpjTknBFm9eq+3jBWQHkSCUpnb3HRQ@mail.gmail.com> (raw)
In-Reply-To: <20120322144122.59d12051.akpm@linux-foundation.org>
On Thu, Mar 22, 2012 at 2:41 PM, Andrew Morton
<akpm@linux-foundation.org> wrote:
>>
>> Use __bitwise for that - check how gfp_t is handled.
>
> So what does __nocast do?
__nocast warns about explicit or implicit casting to different types.
HOWEVER, it doesn't consider two 32-bit integers to be different
types, so a __nocast 'int' type may be returned as a regular 'int'
type and then the __nocast is lost.
So "__nocast" on integer types is usually not that powerful. It just
gets lost too easily. It's more useful for things like pointers. It
also doesn't warn about the mixing: you can add integers to __nocast
integer types, and it's not really considered anything wrong.
__bitwise ends up being a "stronger integer separation". That one
doesn't allow you to mix with non-bitwise integers, so now it's much
harder to lose the type by mistake.
So basic rules is:
- "__nocast" on its own tends to be more useful for *big* integers
that still need to act like integers, but you want to make it much
less likely that they get truncated by mistake. So a 64-bit integer
that you don't want to mistakenly/silently be returned as "int", for
example. But they mix well with random integer types, so you can add
to them etc without using anything special. However, that mixing also
means that the __nocast really gets lost fairly easily.
- "__bitwise" is for *unique types* that cannot be mixed with other
types, and that you'd never want to just use as a random integer (the
integer 0 is special, though, and gets silently accepted iirc - it's
kind of like "NULL" for pointers). So "gfp_t" or the "safe endianness"
types would be __bitwise: you can only operate on them by doing
specific operations that know about *that* particular type.
Generally, you want __bitwise if you are looking for type safety.
"__nocast" really is pretty weak.
Linus
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2012-03-22 22:09 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-21 6:56 [PATCH 00/16] mm: prepare for converting vm->vm_flags to 64-bit Konstantin Khlebnikov
2012-03-21 6:56 ` [PATCH 01/16] mm: introduce NR_VMA_FLAGS Konstantin Khlebnikov
2012-03-21 6:56 ` [PATCH 02/16] mm: use vm_flags_t for vma flags Konstantin Khlebnikov
2012-03-21 6:56 ` [PATCH 03/16] mm/shmem: " Konstantin Khlebnikov
2012-03-21 6:56 ` [PATCH 04/16] mm/nommu: " Konstantin Khlebnikov
2012-03-21 7:08 ` Greg Ungerer
2012-03-21 7:20 ` Konstantin Khlebnikov
2012-03-21 12:01 ` [PATCH v2 " Konstantin Khlebnikov
2012-03-23 6:47 ` Greg Ungerer
2012-03-21 6:56 ` [PATCH 05/16] mm/drivers: " Konstantin Khlebnikov
2012-03-21 10:34 ` Laurent Pinchart
2012-03-21 14:46 ` Greg Kroah-Hartman
2012-03-21 6:56 ` [PATCH 06/16] mm/x86: " Konstantin Khlebnikov
2012-03-21 6:57 ` H. Peter Anvin
2012-03-21 6:56 ` [PATCH 07/16] mm/arm: " Konstantin Khlebnikov
2012-03-22 21:21 ` Andrew Morton
2012-03-21 6:56 ` [PATCH 08/16] mm/unicore32: " Konstantin Khlebnikov
2012-03-27 3:38 ` Guan Xuetao
2012-03-27 5:58 ` Konstantin Khlebnikov
2012-03-27 7:50 ` Guan Xuetao
2012-03-21 6:56 ` [PATCH 09/16] mm/ia64: " Konstantin Khlebnikov
2012-03-21 6:56 ` [PATCH 10/16] mm/powerpc: " Konstantin Khlebnikov
2012-03-21 6:56 ` [PATCH 11/16] mm/s390: " Konstantin Khlebnikov
2012-03-21 6:57 ` [PATCH 12/16] mm/mips: " Konstantin Khlebnikov
2012-03-21 6:57 ` [PATCH 13/16] mm/parisc: " Konstantin Khlebnikov
2012-03-21 6:57 ` [PATCH 14/16] mm/score: " Konstantin Khlebnikov
2012-03-21 6:57 ` [PATCH 15/16] mm: cast vm_flags_t to u64 before printing Konstantin Khlebnikov
2012-03-21 6:57 ` [PATCH 16/16] mm: vm_flags_t strict type checking Konstantin Khlebnikov
2012-03-21 12:11 ` [PATCH v2 " Konstantin Khlebnikov
2012-03-21 10:06 ` [PATCH 00/16] mm: prepare for converting vm->vm_flags to 64-bit Minchan Kim
2012-03-21 13:16 ` Konstantin Khlebnikov
2012-03-22 5:39 ` Minchan Kim
2012-03-22 6:22 ` Benjamin Herrenschmidt
2012-03-24 14:46 ` Konstantin Khlebnikov
2012-03-24 15:00 ` Konstantin Khlebnikov
2012-03-24 23:50 ` Benjamin Herrenschmidt
2012-03-25 7:55 ` Konstantin Khlebnikov
2012-03-22 21:26 ` Andrew Morton
2012-03-22 21:28 ` Al Viro
2012-03-22 21:41 ` Andrew Morton
2012-03-22 21:57 ` Al Viro
2012-03-22 22:05 ` Konstantin Khlebnikov
2012-03-22 22:24 ` Konstantin Khlebnikov
2012-03-22 22:39 ` Linus Torvalds
2012-03-22 22:52 ` Konstantin Khlebnikov
2012-03-22 23:09 ` Andrew Morton
2012-03-23 1:42 ` Al Viro
2012-03-22 22:08 ` Linus Torvalds [this message]
2012-03-23 16:19 ` KOSAKI Motohiro
2012-03-30 2:19 ` Al Viro
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+55aFzbhYvw7Am9EYgatpjTknBFm9eq+3jBWQHkSCUpnb3HRQ@mail.gmail.com \
--to=torvalds@linux-foundation.org \
--cc=akpm@linux-foundation.org \
--cc=benh@kernel.crashing.org \
--cc=hughd@google.com \
--cc=khlebnikov@openvz.org \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux@arm.linux.org.uk \
--cc=minchan@kernel.org \
--cc=viro@zeniv.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).