friedl@mtndew.Tustin.CA.US (Steve Friedl) (09/09/90)
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).
Do people porting software to lots of different machines
generally avoid bitfields?
Steve
--
Stephen J. Friedl, KA8CMY / I speak for me only / Tustin, CA / 3B2-kind-of-guy
+1 714 544 6561 / friedl@mtndew.Tustin.CA.US / {uunet,attmail}!mtndew!friedl
Steve's bright idea #44: COBOL interface library for X Windowsc164-bd@falstaff.uucp (John D. Mitchell) (09/09/90)
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>
kam2@csd4.csd.uwm.edu (Keith A Mcmillan) (09/11/90)
In article <508@mtndew.Tustin.CA.US> friedl@mtndew.Tustin.CA.US (Steve Friedl) writes: >Hiho folks, > > Do people porting software to lots of different machines >generally avoid bitfields? > Yes. Alternatively, you can define the structure of the fields inside of a #ifdef for the machine type. This may require you to do a bit of work to determine what order the bits go in, but it saves re-writing code or mucking up your code with #ifdefs. a brief example is given below: #define VAX #ifdef VAX ... int one:1; int two:1; ... #elseif ... int sixteen:1; int fifteen:1; ... int one:1; ... #endif That way, your structure always puts the bits in the same order in the word, regardless of what machine, you are on. All you have to do is define VAX (or whatever) or not. This can be done on the command line to CC with the -D option. >Steve's bright idea #44: COBOL interface library for X Windows Great! After that, how about Algol? ;-) Keith
chip@tct.uucp (Chip Salzenberg) (09/11/90)
According to kam2@csd4.csd.uwm.edu (Keith A Mcmillan): >Alternatively, you can define the structure of the fields inside of >a #ifdef for the machine type. This strategy is a big-time loser when you have more than one compiler on your system. For example, SCO Unix has AT&T and Microsoft compilers, and I've installed GCC. Do they have the same bitfield algorithm? Beats me -- but I wouldn't count on it. -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip>
jimp@cognos.UUCP (Jim Patterson) (09/14/90)
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 don't know of any "modern" C compilers which don't support bitfields. However, there are a few things you should look out for: 1. Signed-ness. It's likely a good idea to avoid plain "int" bitfields, because some compilers will interpret it as signed while others will interpret it as unsigned. VAX/VMS C is an example of a compiler of the former variety. Unfortunately the ANSI X3J11 standard opted for the "status quo", and didn't attemt to correct this difference between compilers so plain "int" bitfields are essentially useless in portable code. You can use "signed int" to get an explicitly signed bitfield if you have an ANSI compiler, but this won't port to most non-ANSI compilers. For maximally portable code, Use "unsigned int" only when declaring bitfields. 2. The other main compiler difference you will see is alignment. Many compilers, particulary on RISC machines, give any group of bit-fields "int" alignment and padding, even if you're only using one or two bits. Other compilers align bit-fields on an addressable-unit (i.e. char) basis, i.e. they are packed as tightly as possible. Various compilers have extensions to change the alignment (e.g. "unsigned short field : 5"), but while in common practice they are NOT ANSI-standard. -- Jim Patterson Cognos Incorporated UUCP:uunet!mitel!sce!cognos!jimp P.O. BOX 9707 PHONE:(613)738-1440 3755 Riverside Drive Ottawa, Ont K1G 3Z4