Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!zaphod.mps.ohio-state.edu!mips!sdd.hp.com!ucsd!dog.ee.lbl.gov!pasteur!falstaff!c164-bd
From: c164-bd@falstaff.uucp (John D. Mitchell)
Newsgroups: comp.lang.c
Subject: Re: How portable are bitfields?
Summary: Depends :-)
Message-ID: <27620@pasteur.Berkeley.EDU>
Date: 9 Sep 90 12:47:44 GMT
References: <508@mtndew.Tustin.CA.US>
Sender: news@pasteur.Berkeley.EDU
Reply-To: c164-bd@falstaff.UUCP (John D. Mitchell)
Followup-To: comp.lang.c
Distribution: usa
Organization: University of California, Berkeley
Lines: 26

In article <508@mtndew.Tustin.CA.US> friedl@mtndew.Tustin.CA.US (Steve Friedl) writes:
>Hiho folks,
>
>     In our Allegedly Portable Software we have run into some
>code that could naturally use bitfields to nice advantage (in
>readability, at least), and I wonder how reasonably I can rely on
>compilers to support them properly.  I generally know the
>portability concerns for bitfields when they are supported
>properly by the compiler, but I seem to notice that bugs related
>to bitfields seem to have had problems for as long as I can
>remember (since the early eighties).
[stuff deleted]

I bow to those porting gurus out there but my experience says that
if you're using the bit-fields to do strange, miraculous fiddling
of hardware dependant things then no it most likely will not port
to other machines.  If you are doing something where your bit-fields
adhere to the ANSI rules that be and only do things such as setting
and testing the field and don't use more than 16-bits (i.e. minimum
sizeof(int)) then it should port very well.  My inkling is that
if you're code's portability is that big of an issue don't do it!

Good luck,
	John Mitchell

#include <std.disclaimer>