thomson@utcsrgv.UUCP (Brian Thomson) (08/12/83)
Our 4.1BSD C compiler supports signed bit fields, in variance with my 1978 K&R book which states (p. 138) that "fields are unsigned". Is this an example of language evolution in action, or can the compiler be dismissed as an incorrect implementation of C? I don't mean this as a religious question; rather, does the C user community see signed bitfields becoming a de facto standard? I believe (but am not sure) that the System III Vax compiler also implements signed fields. -- Brian Thomson, CSRG Univ. of Toronto {linus,ihnp4,uw-beaver,floyd,utzoo}!utcsrgv!thomson
geoff@utcsstat.UUCP (08/13/83)
Despite the tutorial discussion on p. 138 of Kernighan & Ritchie, which says ``fields are unsigned'', appendix A, the C reference manual, says in section 8.5 on p. 197: The language does not restrict the types of things that are declared as fields, but implementations are not required to support any but integer fields. Moreover, even int fields may be considered to be unsigned. On the PDP-11, fields are not signed and have only integer values. Thus one is only guaranteed that unsigned fields will be available in a given implementation, but there may be int or even other fields. In portable code, one must not assume the existence of fields other than unsigned fields. When in doubt, read the manual, not the tutorial. Geoff Collyer, U. of Toronto
alan@allegra.UUCP (08/13/83)
I am not sure where signed bit fields stand in the current definition of the C language, but I do have some knowledge of PCC, having recently constructed a PCC-based C cross- compiler. PCC allows you to generate a non-standard compiler. For example, there's a flag you can set which makes long bit fields ok. Consequently, the fact that an implementation of PCC lets you do something doesn't mean it's kosher C. Alan Driscoll Bell Labs, Murray Hill
henry@utzoo.UUCP (Henry Spencer) (08/15/83)
Actually, if you want portable code, you should avoid bitfields entirely. Many C implementations botch them. They aren't really very well designed in the first place; Dennis Ritchie has been heard to refer to them as "a botch and a blemish". -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
alan@allegra.UUCP (08/15/83)
If many C implementations botch bit fields, that's still no reason to avoid them. Sounds like a reason to get a better compiler... Alan Driscoll Bell Labs, Murray Hill
henry@utzoo.UUCP (Henry Spencer) (08/28/83)
Alan Driscoll observes: If many C implementations botch bit fields, that's still no reason to avoid them. Sounds like a reason to get a better compiler... Sorry, Alan, but this is another manifestation of the self-centered, "I'm-all-right-Jack" attitude that enrages people who are trying to actually *use* other folks' "portable" software. If my software is being written only for use at my installation, OK. But if it's being written for export, then it is important for me to realize that there are a lot of compilers out there that botch bitfields, and that it is not in my power to change this. This is ugly and unpleasant, but it's the way the world is. By its nature, writing highly portable software involves accepting a lowest-common-denominator environment. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry