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 uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc