On Wed, 17 Sep 2003 11:02:45 -0400 (EDT) Alan Stern <[EMAIL PROTECTED]> wrote:
| On Tue, 16 Sep 2003, Randy.Dunlap wrote:
|
| > On Tue, 16 Sep 2003 17:31:21 -0700 David Brownell <[EMAIL PROTECTED]> wrote:
| >
| > | But I've got a couple questions about this one, maybe you know the
| > | answers to them:
| > |
| > | > - unsigned no_interrupt : 1,
| > | > - zero : 1,
| > | > - short_not_ok : 1;
| > | > + unsigned no_interrupt:1,
| > | > + zero:1,
| > | > + short_not_ok:1;
| > |
| > | I tried this and it made "no_interrupt" appear in the kerneldoc.
| > | But NOT the other two bits. Is someone fixing kerneldoc bugs,
| > | so that issue can have some useful resolution?
| >
| > Oh, bad. Sorry about that. Not that I know of.
| >
| > | Related question, I'm guessing that having each one on a line
| > | by itself would make kerneldoc happy. But as I recall, that'd
| > | be at the cost of making the bits live in separate words, which
| > | is waste I'd rather avoid ... know if that's true?
| >
| > Yes, if I recall correctly, that would allocate a new <unsigned>
| > for each one instead of a series of bits in one <unsigned>....
|
| It may depend on the particular compiler you use. I just tried the
| experiment using gcc 2.96 from RedHat 7.2 on a Pentium-class machine.
| Given the following structure definition:
|
| struct s {
| unsigned i:1, j:1;
| unsigned k:1;
| unsigned h:1;
| };
|
| and invoked with -O -S the compiler placed all four bits in the same byte
| (determined by reading the assembler-code output). It did the same when
| invoked with -O2 -S although the code generated was different.
I think that you have the right answer. The ANSI/ISO/IEC 1999 C
standard spells it out fairly well. I should have looked there:
6.7.2.1 Structure and union specifiers
10 An implementation may allocate any addressable storage unit large enough to hold a
bit- field. If enough space remains, a bit-field that immediately follows another
bit-field in a structure shall be packed into adjacent bits of the same unit. If
insufficient space remains, whether a bit-field that does not fit is put into the next
unit or overlaps adjacent units is implementation-defined. The order of allocation of
bit-fields within a unit (high-order to low-order or low-order to high-order) is
implementation-defined. The alignment of the addressable storage unit is unspecified.
11 A bit-field declaration with no declarator, but only a colon and a width, indicates
an unnamed bit-field.105) As a special case, a bit-field structure member with a width
of 0 indicates that no further bit-field is to be packed into the unit in which the
previous bit-field, if any, was placed.
--
~Randy
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
