About bitfields

[Régis Troadec]

Hi all,

I follow c.l.c. for only a short time and I would like to know
why there isn't anything concerning bitfields among the FAQs.

Is it because ...
1. of portability issues?
2. bitfields aren't enough useful to be discussed?
3. of the low frequency of questions concerning this topic?
4. of anything else?...

Or perhaps it would be interesting to mention bitfields among
the FAQs with a relevant example?

Greetings, Regis

 

[Darrell Grainger]

Hi all,

I follow c.l.c. for only a short time and I would like to know
why there isn't anything concerning bitfields among the FAQs.

Is it because ...
1. of portability issues?
2. bitfields aren't enough useful to be discussed?
3. of the low frequency of questions concerning this topic?
4. of anything else?...

Or perhaps it would be interesting to mention bitfields among
the FAQs with a relevant example?

FAQ is an acronym for Frequently Asked Questions (or Frequently Answered
Questions). If there is not a common question about bitfields being asked
then there will be no FAQ for them.

Having been in and out of comp.lang.c for the past 15 years and never
remember a specific question about bitfields coming up. So I'm going to go
with option 3 from your list.

 

[Richard Heathfield]

Hi all,

I follow c.l.c. for only a short time and I would like to know
why there isn't anything concerning bitfields among the FAQs.

Is it because ...
1. of portability issues?
2. bitfields aren't enough useful to be discussed?
3. of the low frequency of questions concerning this topic?
4. of anything else?...

Or perhaps it would be interesting to mention bitfields among
the FAQs with a relevant example?

The index in the book version says:

bitfields 46-7
and Boolean types 141
portability of 46

Turning to those pages, I find that questions 2.25 and 2.26 are all about
bitfields, and 9.1 references them in a footnote.

Checking these in the online version, I note that questions 2.25 and 2.26
are entirely absent, and that the footnote is absent from 9.1.

My conclusion? Bitfields are a vital aspect of modern C programming, and
Steve Summit ruthlessly exploits this fact for hard-nosed commercial
reasons. This also explains why he's never around comp.lang.c these days -
he's too busy sunning himself on the yacht he bought with the royalties of
the book version of the FAQ.

 

[Dan Pop]

FAQ is an acronym for Frequently Asked Questions (or Frequently Answered
Questions). If there is not a common question about bitfields being asked
then there will be no FAQ for them.

Having been in and out of comp.lang.c for the past 15 years and never
remember a specific question about bitfields coming up. So I'm going to go
with option 3 from your list.

It's not as much a matter of frequency (such questions do arise from time
to time) as a matter of those questions not having enough in common to be
worth an entry (or more) in the FAQ.

Dan

 

[CBFalconer]

The index in the book version says:

bitfields 46-7
and Boolean types 141
portability of 46

Turning to those pages, I find that questions 2.25 and 2.26 are
all about bitfields, and 9.1 references them in a footnote.

Checking these in the online version, I note that questions 2.25
and 2.26 are entirely absent, and that the footnote is absent
from 9.1.

My conclusion? Bitfields are a vital aspect of modern C
programming, and Steve Summit ruthlessly exploits this fact for
hard-nosed commercial reasons. This also explains why he's never
around comp.lang.c these days - he's too busy sunning himself on the
yacht he bought with the royalties of the book version of the FAQ.

Well, you should be expert on that facet. Are you having major
problems spending the excess royalties from "C Unleashed"?

Note to OP: The above two (2) paragraphs could use a <sarcasm>
indicator. In practice bitfields are not well suited to portable
programming, due to the lack of standards about them. Masks can
generate portable code.

 

[Richard Heathfield]

Richard Heathfield wrote:


Well, you should be expert on that facet. Are you having major
problems spending the excess royalties from "C Unleashed"?

Yes, I'm afraid so. Let the reader understand.

 

[Dan Pop]

Note to OP: The above two (2) paragraphs could use a <sarcasm>
indicator. In practice bitfields are not well suited to portable
programming, due to the lack of standards about them. Masks can
generate portable code.

Nonsense. Bitfields are perfectly well suited to portable programming:
let the compiler take care of the masking job.

They are not well suited at mapping an externally imposed bit layout,
but the need to do such a thing hardly arises in a portable programming
context. And if it doesn't have to be done portably, it usually can be
done, by observing how the compiler allocates the bit fields.

Dan

 

[CBFalconer]

Nonsense. Bitfields are perfectly well suited to portable programming:
let the compiler take care of the masking job.

They are not well suited at mapping an externally imposed bit layout,
but the need to do such a thing hardly arises in a portable programming
context. And if it doesn't have to be done portably, it usually can be
done, by observing how the compiler allocates the bit fields.

In some sense, such as packing, you are correct. However I
conceive of bitfields as more suited to matching imposed
constraints, such as a status word from a peripheral (which is
what you said), and there they may well not even port between
releases of the same compiler.

The user has to know what he is doing in order to use them safely.

 

[Dan Pop]

In some sense, such as packing, you are correct. However I
conceive of bitfields as more suited to matching imposed
constraints, such as a status word from a peripheral (which is
what you said), and there they may well not even port between
releases of the same compiler.

In theory. In practice, implementors avoid changing their compilers in
ways that can break existing correct code. Moreover, different
implementors usually adhere to the same set of conventions on the same
platform.

The user has to know what he is doing in order to use them safely.

This is true for each and every feature of the C language.

Dan