Re: Help with cross-endian bitfields?

["D.J. Barrow" <barrow_dj@yahoo.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 2607 bytes --]


If you are using gcc using __attribute__(packed)
may help otherwise the compiler may optimise alignment
info gcc for more info.
struct blah
{
   uchar a : 3;
   uchar b : 3;
   uchar c : 2;
} __attribute__(packed);

to pack the array it also would be more correct to
use unsigned as opposed to uchar.

struct blah
{
   unsigned a : 3;
   unsigned b : 3;
   unsigned c : 2;
} __attribute__(packed);

I personally would be expecting to use ((*((u8
*)&blah[0]))&0x0e0)>>5 to get the info from blah.a on
both little & big endian machines.



--- Daniel Jacobowitz <drow@false.org> wrote:
>
> On Fri, May 05, 2000 at 03:27:21PM -0400,
> jlquinn@us.ibm.com wrote:
> >
> > Hi, all.  I'm working on getting the Advansys
> driver working and what
> > appears to be the final stumbling block is a
> difference in the layout of
> > bitfields between little-endian and big-endian
> systems.  In particular,
> > there are structs like the following:
> >
> > struct blah {
> >   uchar a : 3;
> >   uchar b : 3;
> >   uchar c : 2;
> > }
> >
> > On a little endian machine, this works like I
> expect.  (blah & 0x07) ==
> > blah.a is true.  On linuxppc (and apparently MacOS
> as well), this is NOT
> > true.  blah.a refers to the 3 most significant
> bits.  The linuxppc behavior
> > seems counterintuitive to me because I expected
> each successive member in a
> > struct to be the next physical piece of data I
> encounter.
> >
> > Can someone tell me what's going on here?  Am I
> going to have to have
> > ifdef's on these structs, or resort to mask
> macros, or is there a
> > reasonable solution here.
>
> As Dan Malek said, there is no defined ordering.
> The compiler is free
> to do whatever it wishes.  You can't assume that.
> (I think.)
>
> Also, by your intuition, the obvious thing IS
> happening.  Remember that
> we are big-endian - the first thing in memory is
> big-endian.  Thus, it
> follows logically that a should be in the first
> three (most
> significant) bits.
>
> Dan
>
> /--------------------------------\
> /--------------------------------\
> |       Daniel Jacobowitz        |__|        SCS
> Class of 2002       |
> |   Debian GNU/Linux Developer    __    Carnegie
> Mellon University   |
> |         dan@debian.org         |  |
> dmj+@andrew.cmu.edu      |
> \--------------------------------/
> \--------------------------------/
>
>

=====
D.J. Barrow Linux for S/390 kernel developer
eMail: djbarrow@de.ibm.com,barrow_dj@yahoo.com
Phone: +49-(0)7031-16-2583
IBM Germany Lab, Schönaicherstr. 220, 71032 Böblingen


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/