#More bit field problems
6 messages in this thread
Mike –
Did some more playing with bit fields. I put four bit fields of varying
lengths in with other normal fields ( short, char, etc.). In each case it
seemed like the bit fields packed to a byte each, rather than the requested
number of bits, according to sizeof(). Each set of fields was made so they
added up to a byte; when I replaced the fields with a byte (i.e., removed
all bit fields and added a char) the counts were what they should have been
had the bit fields come out correctly (even odd-length records).
I'm beginning to be of the opinion that this is a bug, rather than a
word-size-minimum-on-a-struct type of thing. Please let me know what you
find out. Thanks …
Harry
No, its definitely not a bug. Both ANSI and K&R essentially say that
bit-field implimentation is entirely implimentation-defined, and Lattice's
implimentation doesn't seem to do anything really bizarre. Perhaps it does
not perform optimally on a 68000, but this only shows that bitfields are
generally pretty kludgy, entirely non-portable, and dangerous to use if you
don't really know what you're doing. In many cases its better to use an
int or long or whatever, and do the masking and shifting yourself.
-Mike
Mike –
But that essentially eliminates the utility of the feature. If I really
wanted to do the masking and shifting myself, I'd write the thing in
assembler. The other compilers I've worked on (three C, one Pascal <where
we used SETs to access bits in a word>) produced the code to use the
feature as it was (or seems to me to be) intended.
Perhaps Lattice could "adjust" (since you won't like it if I say "fix"
8^) ) this feature in a future release. I use Turbo C and Microsoft C on
the PCs at work, and they both handle the situation as I would expect
(actually, that's _why_ I expect it – I essentially learned the finer
points of C using these programs). The Pascal compiler on my Atari (I know,
this is C we're discussing, but it's an equivalent feature) will pack a
16-item set into a word for bit access. There's plenty of precedent for
implementing bit fields this way, and I'm just disappointed that Lattice
chose not to do so.
Anyway, my program does work, and I do use the mask-and-shift method
since there is no other way. I just think there should be. Nothing personal
<grin>.
Harry
My point Harry was that bitfields, almost by definition, are extremely
volatile in their implimentation. It would be perfectly valid for Lattice
or Aztec or anybody to change how they handled bitfields across releases,
if they wish (by both K&R and ANSI reckoning). If you've got to _count_ on
the exact bitfield implimentation, I still maintain you shouldn't be using
bitfields then, because even if your code works now, it may not work
tomorrow when a new version of a compiler comes out that does 'em
differently.
-Mike
Mike,
I agree that the standard allows a certain (lot) of lattitude for the
compiler writer. HOWEVER … I (and probably most others) would expect bit
fields to be packed tightly in the environment's natural word size. The
variations I would expect would be left/right or right/left packing
(although I have a DEFINITE preference for left/right on the 68k series,
but probably right/left on the PeeCee). I could also see why a compiler
writer might want to pad out words. BUT … I don't see any logical sense
to starting each bit field on a byte boundary, or padding each out to an
integral number of bytes, which I seem to remember reading here the other
day. I haven't had the chance to see what Manx does yet … I rarely use
the things … but being the controversial type due to some of my previous
messages, I just thought I'd stir things up a little <grin>.
🙂
Jerry.
Well…there's lots of places in life where there's "what there should be"
and "what there is". ANSI C has given implimentors so much lattitude in
bitfields that I've found its usually alot less painful to just avoid them
altogether and roll my own.
-Mike