bit fields ordering

[Jonathan Maddison]

If I have the following structure:

typedef union BYTE {
uint8_t bite;
struct {
uint8_t b0 : 1;
uint8_t b1 : 1;
uint8_t b2 : 1;
uint8_t b3 : 1;
uint8_t b4 : 1;
uint8_t b5 : 1;
uint8_t b6 : 1;
uint8_t b7 : 1;
} bits;
} BYTE;

On my box, with gcc I get the msb stored in b7, all the way though to
the lsb stored in b0. BUT, how portable is the above code - can I assume
that the fields will always be ordered in such a way?

[Walter Roberson]

In article <sl*********************@HAL.honeypot>,
Jonathan Maddison <jmaddi gmail > wrote:

If I have the following structure: typedef union BYTE {
uint8_t bite;
struct {
uint8_t b0 : 1;
uint8_t b1 : 1;
uint8_t b2 : 1;
uint8_t b3 : 1;
uint8_t b4 : 1;
uint8_t b5 : 1;
uint8_t b6 : 1;
uint8_t b7 : 1;
} bits;
} BYTE; On my box, with gcc I get the msb stored in b7, all the way though to
the lsb stored in b0. BUT, how portable is the above code - can I assume
that the fields will always be ordered in such a way?

No, the order of bits within a char is undefined by the standard.

Besides, uint8_t only exists on boxes that can support it.
If CHAR_BIT is (say) 9, then uint8_t doesn't exist in the
implementation.
--
Feep if you love VT-52's.

[Keith Thompson]

ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:

In article <sl*********************@HAL.honeypot>,
Jonathan Maddison <jmaddi gmail > wrote:

If I have the following structure:

typedef union BYTE {
uint8_t bite;
struct {
uint8_t b0 : 1;
uint8_t b1 : 1;
uint8_t b2 : 1;
uint8_t b3 : 1;
uint8_t b4 : 1;
uint8_t b5 : 1;
uint8_t b6 : 1;
uint8_t b7 : 1;
} bits;
} BYTE;

On my box, with gcc I get the msb stored in b7, all the way though to
the lsb stored in b0. BUT, how portable is the above code - can I assume
that the fields will always be ordered in such a way?

No, the order of bits within a char is undefined by the standard.

Besides, uint8_t only exists on boxes that can support it.
If CHAR_BIT is (say) 9, then uint8_t doesn't exist in the
implementation.

And the only allowed types for bit fields are int, signed int,
unsigned int, and _Bool (or some other implementation-defined type).

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Emmanuel Delahaye]

Jonathan Maddison wrote on 27/08/05 :

typedef union BYTE {
uint8_t bite;
Do you meant byte ?
struct {
uint8_t b0 : 1;
uint8_t b1 : 1;
uint8_t b2 : 1;
uint8_t b3 : 1;
uint8_t b4 : 1;
uint8_t b5 : 1;
uint8_t b6 : 1;
uint8_t b7 : 1;
} bits;
} BYTE; On my box, with gcc I get the msb stored in b7, all the way though to
the lsb stored in b0. BUT, how portable is the above code - can I assume
that the fields will always be ordered in such a way?

You can't. Bitfields are not portable. For portable interfaces, use
unsigned integers and bitwise operators.

This can help

http://mapage.noos.fr/emdel/clib/ed/inc/bits.h

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"C is a sharp tool"

[Jonathan Maddison]

I thought I posted a reply before, but I seemed to of accidently emailed
Walter instead (sorry Walter :().

On 2005-08-27, Walter Roberson <ro******@ibd.nrc-cnrc.gc.ca> wrote:

No, the order of bits within a char is undefined by the standard. Oh, ok - thanks. Besides, uint8_t only exists on boxes that can support it.
If CHAR_BIT is (say) 9, then uint8_t doesn't exist in the
implementation. Oh I see, damn - I'm going to have to find an elegant workaround for other
systems then. But how common exactly are systems that don't support that type
(or other 8-bit types).
And the only allowed types for bit fields are int, signed int,
unsigned int, and _Bool (or some other implementation-defined type). I am using c99 - so uint8_t should be implementation-defined (except in
some systems as Walter pointed out) - I think...
You can't. Bitfields are not portable. For portable interfaces, use
unsigned integers and bitwise operators. :( I was hoping someone wouldn't say that... Oh well, looks like its my only
option now. This can help

Thanks for the link.

[Don]

Jonathan Maddison <Jo******@HAL.honeypot> wrote in
news:slrndh02ih.1t4.Jo******@HAL.honeypot:

If I have the following structure:

typedef union BYTE {
uint8_t bite;
struct {
uint8_t b0 : 1;
uint8_t b1 : 1;
uint8_t b2 : 1;
uint8_t b3 : 1;
uint8_t b4 : 1;
uint8_t b5 : 1;
uint8_t b6 : 1;
uint8_t b7 : 1;
} bits;
} BYTE;

On my box, with gcc I get the msb stored in b7, all the way though to
the lsb stored in b0. BUT, how portable is the above code - can I assume
that the fields will always be ordered in such a way?

You cannot assume anything, dumbass.

[Simon Biber]

Jonathan Maddison wrote:

On 2005-08-27, Walter Roberson <ro******@ibd.nrc-cnrc.gc.ca> wrote:

Besides, uint8_t only exists on boxes that can support it.
If CHAR_BIT is (say) 9, then uint8_t doesn't exist in the
implementation.

Oh I see, damn - I'm going to have to find an elegant workaround for other
systems then. But how common exactly are systems that don't support that type
(or other 8-bit types).

Not very common. Apparently the C implementation on some old mainframes
had 36-bit words divided into four 9-bit bytes. However, they probably
don't have a compiler available that conforms to the recent standard
that defined the uint8_t style macros.

Some recent embedded systems, particularly Digital Signal Processors
(DSPs), address all memory in 16 or 32 bit chunks, and their C
implementation defines the byte as the native word size. In such an
implementation, sizeof(char), sizeof(short) and sizeof(int) will all be 1.

This causes unexpected results in many common C idioms. For example,
getchar() normally returns a positive int containing the character
value, or else EOF (which is some negative int) if an error or
end-of-file condition occurs. However, if characters require the full
range of the int data type, including what maps to negative numbers,
then there is no space for out-of-band EOF signalling.

If you are writing code for general personal computers, you are very
unlikely to encounter an implementation with a byte size other than 8 bits.

--
Simon.

[Emmanuel Delahaye]

Don wrote on 27/08/05 :

You cannot assume anything, dumbass.

Why being so rude ? Get a life...

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"C is a sharp tool"

[Flash Gordon]

Simon Biber wrote:

Jonathan Maddison wrote:

On 2005-08-27, Walter Roberson <ro******@ibd.nrc-cnrc.gc.ca> wrote:

Besides, uint8_t only exists on boxes that can support it.
If CHAR_BIT is (say) 9, then uint8_t doesn't exist in the
implementation.
Oh I see, damn - I'm going to have to find an elegant workaround for
other
systems then. But how common exactly are systems that don't support
that type
(or other 8-bit types).

Not very common. Apparently the C implementation on some old mainframes
had 36-bit words divided into four 9-bit bytes. However, they probably
don't have a compiler available that conforms to the recent standard
that defined the uint8_t style macros.

Probably true.
Some recent embedded systems, particularly Digital Signal Processors
(DSPs), address all memory in 16 or 32 bit chunks, and their C
implementation defines the byte as the native word size. In such an
implementation, sizeof(char), sizeof(short) and sizeof(int) will all be 1.
How do you define recent? I was working in C on such a system in about
1995 IIRC and I think the compiler was up to version 4.something at the
time, so it had been around for a while.
This causes unexpected results in many common C idioms. For example,
getchar() normally returns a positive int containing the character
value, or else EOF (which is some negative int) if an error or
end-of-file condition occurs. However, if characters require the full
range of the int data type, including what maps to negative numbers,
then there is no space for out-of-band EOF signalling.
Such systems are not generally hosted implementations, and it is only
hosted implementations that are required to provide stdio.h and, indeed,
most of the rest of the standard library.
If you are writing code for general personal computers, you are very
unlikely to encounter an implementation with a byte size other than 8 bits.

That is true. Different sizes of int and long are far more likely in
hosted implementations.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

[Keith Thompson]

Don <do*@127.0.0.1> writes:
[...]

You cannot assume anything, dumbass.

I think we have ourselves a troll. Not only is "Don" is rude; he also
cross-posts to alt.usenet.kooks. I suggest ignoring him, or at least
not following the cross-post.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Malcolm]

"Simon Biber" <ne**@ralmin.cc> wrote

If you are writing code for general personal computers, you are very
unlikely to encounter an implementation with a byte size other than 8
bits.

It's a major engineering blunder not to allow for fast 8-bit addressing in
hardware.
However the snag is that in C there is no "byte" type. There is an argument
for allowing "char" to take unicode.
The current convention is to call unicode characters "wide characters" or
w_char. Unfortunately this then breaks anything that calls stdio (including
fopen), or the string library. So it would be unwise to assume that some
complier writer in the future isn't going to say that "char" is sixteen
bits.
By making as few assumptions as possible, you can to some extent
future-proof your code.

[Emmanuel Delahaye]

Malcolm wrote on 29/08/05 :

It's a major engineering blunder not to allow for fast 8-bit addressing in
hardware.
<way off-topic>
Why ? Who cares ? If a 16-bit access is as fast than a 8-bit access,
why bother ?
</> However the snag is that in C there is no "byte" type. There is an argument
for allowing "char" to take unicode.

Not char, but wchar_t.

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"There are 10 types of people in the world today;
those that understand binary, and those that dont."

[Peter Nilsson]

Emmanuel Delahaye wrote:

Malcolm wrote on 29/08/05 :

However the snag is that in C there is no "byte" type. There is an argument
for allowing "char" to take unicode.

Not char, but wchar_t.

No, he means char, and I agree. But I'm resigned to it not happening in
C.

--
Peter