This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Memory corruption due to word sharing
- From: Linus Torvalds <torvalds at linux-foundation dot org>
- To: David Miller <davem at davemloft dot net>
- Cc: matz at suse dot de, jkosina at suse dot cz, walters at verbum dot org, jack at suse dot cz, linux-kernel at vger dot kernel dot org, linux-ia64 at vger dot kernel dot org, dsterba at suse dot cz, ptesarik at suse dot cz, rguenther at suse dot de, gcc at gcc dot gnu dot org
- Date: Wed, 1 Feb 2012 10:57:57 -0800
- Subject: Re: Memory corruption due to word sharing
- References: <CA+55aFxmdskUXX1iBaPx7rUGD95UqNJxhe1BLeVtZjqHjBpsPA@mail.gmail.com> <alpine.LRH.2.00.1202011808240.22725@twin.jikos.cz> <Pine.LNX.4.64.1202011818570.25409@wotan.suse.de> <20120201.130905.1131458895704793597.davem@davemloft.net>
On Wed, Feb 1, 2012 at 10:09 AM, David Miller <davem@davemloft.net> wrote:
>
> Personally I've avoided C bitfields like the plague in any code I've
> written.
I do agree with that. The kernel largely tries to avoid bitfields,
usually because we have some really strict rules about different
bitfields, but also because initialization of bitfields tends to
result in gcc generating an incredible mess of the code (while
"explicit bits" allows us to just set all the fields in one go, and
know what the result is).
So core kernel data structures tend to be things like "unsigned long",
together with our various bitop functions that have explicit atomicity
(or non-atomicity) guarantees on a bit-per-bit basis.
Sometimes bitfields are really convenient, though, and allow for much
more natural syntax.
I'm not surprised this issue came up in a filesystem, for example.
Linus