On Tuesday 27 October 2009 13:46:19 Chris Gray wrote:
> On Tuesday 27 October 2009 08:54:50 Ricard Wanderlof wrote:
> > It can produce more readable, less error-prone C code though. We use
> > hardware register definitions such as
> >
> > typedef struct {
> > unsigned int x : 8;
> > unsigned int y : 8;
> > unsigned int control_bit : 1;
> > unsigned int dummy1 : 15;
> > } reg_foo;
> >
> > at great length for the C definitions for the registers in our chips, and
> > it really does avoid nasty errors that crop up when using shifting and
> > masking.
>
> I gave up on bitfields the day I ran something like that through two
> compilers and one decided that x was "obviously" the high-order byte of
> the word and the other decided it was "obviously" the low-order one. Oh
> yes and they made opposite decisions about signedness too, but at least
> you can control that (as in your example). So now I just write little
> inlined functions or macros to do the manipulations.since i dont know the exact issue with the compilers in question (endianness maybe ?), i dont think those drawbacks are applicable to Ricard's usage. doing bit fields for a specific platform means your code is constrained to that platform, so portability isnt a real concern. we do similar things for hardware registers for the same reasons Ricard's cites. -mike
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
