Colon (:) syntax in defining fields in a struct

[Raj Kotaru]

Hello all,

I recently came across the following segment of code that defines a C
struct:

typedef struct
{
unsigned char unused_bits:4;
unsigned char wchair_state:2;
} xyz;

What do the numbers 4 and 2 refer to?

If I define a second struct as below:

typedef struct
{
unsigned char unused_bits;
unsigned char wchair_state;
} abc;
and then declare

void main(void)
{
xyz _xyz;
abc _abc;
}

In terms of memory allocation, is there any difference between that
allocated for _xyz and _abc?

Any feedback would be much appreciated.

Thanks
Raj

[Shark Venue]

":" means bit-allocation.
System will allocate 1 byte to struct _xyz and 2 byte to struct _abc.
Here is mem structure chart:
_______________ _______________ _______________ ____
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |
-------------------------------------------------
|<- _xyz.u_bits ->|<- _xyz.w->|

_______________ __
|1|2|3|4|5|6|7| 8| <---- _abc.u_bits;
+-+-+-+-+-+-+-+-+
|1|2|3|4|5|6|7| 8| <---- _abc.w
-----------------
That is,and works .
I really want you get it.

--
Shark Vanue

[SM Ryan]

ra********@hotm ail.com (Raj Kotaru) wrote:
# Hello all,
#
# I recently came across the following segment of code that defines a C
# struct:
#
# typedef struct
# {
# unsigned char unused_bits:4;
# unsigned char wchair_state:2;
# } xyz;
#
# What do the numbers 4 and 2 refer to?

unused_bits is four bits wide and wchair_state is two bits. The fields may
be packed as tightly as possible, in one char sized unit possibly.

On a typical CPU and C implementation, without the field widths, the
struct would be two characters wide, and only one character wide with
the above.

#
# If I define a second struct as below:
#
# typedef struct
# {
# unsigned char unused_bits;
# unsigned char wchair_state;
# } abc;
#
#
# and then declare
#
# void main(void)
# {
# xyz _xyz;
# abc _abc;
# }
#
# In terms of memory allocation, is there any difference between that
# allocated for _xyz and _abc?

Add
printf("%d %d\n",sizeof(xy z),sizeof(abc)) ;
I would expect to see it print
1 2

--
SM Ryan http://www.rawbw.com/~wyrmwif/
One of the drawbacks of being a martyr is that you have to die.

[Keith Thompson]

ra********@hotm ail.com (Raj Kotaru) writes:

I recently came across the following segment of code that defines a C
struct:

typedef struct
{
unsigned char unused_bits:4;
unsigned char wchair_state:2;
} xyz;

Look up "bit fields" in any C textbook.

--
Keith Thompson (The_Other_Keit h) 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.

[Kenneth Brody]

Shark Venue wrote:

":" means bit-allocation.
System will allocate 1 byte to struct _xyz and 2 byte to struct _abc.
Here is mem structure chart:
_______________ _______________ _______________ ____
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |
-------------------------------------------------
|<- _xyz.u_bits ->|<- _xyz.w->|

I don't believe the standard specifies the order in which bits are
allocated. If that's the case, you may have:

-------------------------------------------------
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |
-------------------------------------------------
|<- _xyz.w->|<- _xyz.u_bits ->|

Or even:

-------------------------------------------------
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |
-------------------------------------------------
|<- _xyz.u_bits ->|
-------------------------------------------------
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |
-------------------------------------------------
|<- _xyz.w->|

[...]

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer .h> |
+-------------------------+--------------------+-----------------------------+

[Peter Shaggy Haywood]

Groovy hepcat SM Ryan was jivin' on Sat, 28 Aug 2004 16:33:30 -0000 in
comp.lang.c.
Re: Colon (:) syntax in defining fields in a struct's a cool scene!
Dig it!

ra********@hot mail.com (Raj Kotaru) wrote:
# Hello all,
#
# I recently came across the following segment of code that defines a C
# struct:
#
# typedef struct
# {
# unsigned char unused_bits:4;
# unsigned char wchair_state:2;
# } xyz;
#
# What do the numbers 4 and 2 refer to?

unused_bits is four bits wide and wchair_state is two bits. The fields may
be packed as tightly as possible, in one char sized unit possibly.

On a typical CPU and C implementation, without the field widths, the
struct would be two characters wide, and only one character wide with
the above.
It should be pointed out, though, that unsigned char is non-portable
for the type of a bit field. Only a qualified or unqualified version
of signed int, unsigned int or _Bool (in C99) are portable.
# If I define a second struct as below:
#
# typedef struct
# {
# unsigned char unused_bits;
# unsigned char wchair_state;
# } abc;
#
# and then declare
#
# void main(void)
Pay attention (Raj Kotaru)! I'm only going to say this a billion
times or so. The main() function is supposed to return an int, not
void. Portable return values for main() are 0, EXIT_SUCCESS and
EXIT_FAILURE, the latter two being macros defined in stdlib.h.

int main(void)# {
# xyz _xyz;
# abc _abc;
return 0;# }
#
# In terms of memory allocation, is there any difference between that
# allocated for _xyz and _abc?

Add
printf("%d %d\n",sizeof(xy z),sizeof(abc)) ;
I would expect to see it print
1 2

I would expect the unexpected. When you invoke the wrath of the
undefined behaviour gods, you never really know what to expect. Well,
sometimes you can make a reasonable guess, but it can always go wrong
and do something you least expect.
Instead, try this:

printf("sizeof xyz = %lu, sizeof abc = %lu\n",
(unsigned long)sizeof xyz,
(unsigned long)sizeof abc);

--

Dig the even newer still, yet more improved, sig!

http://alphalink.com.au/~phaywood/
"Ain't I'm a dog?" - Ronny Self, Ain't I'm a Dog, written by G. Sherry & W. Walker.
I know it's not "technicall y correct" English; but since when was rock & roll "technicall y correct"?

[Karthik Kumar]

Raj Kotaru wrote:

Hello all,

I recently came across the following segment of code that defines a C
struct:

typedef struct
{
unsigned char unused_bits:4;
unsigned char wchair_state:2;
} xyz;

What do the numbers 4 and 2 refer to?
Look up for "Bit Fields and C " in Google.

If I define a second struct as below:

typedef struct
{
unsigned char unused_bits;
unsigned char wchair_state;
} abc;
and then declare

void main(void)
{
xyz _xyz;
abc _abc;
}

In terms of memory allocation, is there any difference between that
allocated for _xyz and _abc?

Bit Fields are generally used to pack data to conserve spacee.
So the two structs would have different sizes altogether.
--
Karthik.

[Fao, Sean]

Peter Shaggy Haywood wrote:

# In terms of memory allocation, is there any difference between that
# allocated for _xyz and _abc?

Add
printf("%d %d\n",sizeof(xy z),sizeof(abc)) ;
I would expect to see it print
1 2

I would expect the unexpected. When you invoke the wrath of the
undefined behaviour gods, you never really know what to expect. Well,
sometimes you can make a reasonable guess, but it can always go wrong
and do something you least expect.
Instead, try this:

printf("sizeof xyz = %lu, sizeof abc = %lu\n",
(unsigned long)sizeof xyz,
(unsigned long)sizeof abc);

Ok, you've got me! Why is the above modification necessary and why
could the original invoke undefined behavior?

P.S.
I waited about two hours for my reply to show up on my news server and
still haven't seen it. I apologize if the original finally shows up.

--
Sean

[Dan Pop]

In <1J************ ***@news.abs.ne t> "Fao, Sean" <en**********@y ahoo.comI-WANT-NO-SPAM> writes:

Peter Shaggy Haywood wrote:

>># In terms of memory allocation, is there any difference between that
# allocated for _xyz and _abc?

Add
printf("%d %d\n",sizeof(xy z),sizeof(abc)) ;
I would expect to see it print
1 2

I would expect the unexpected. When you invoke the wrath of the
undefined behaviour gods, you never really know what to expect. Well,
sometimes you can make a reasonable guess, but it can always go wrong
and do something you least expect.
Instead, try this:

printf("sizeof xyz = %lu, sizeof abc = %lu\n",
(unsigned long)sizeof xyz,
(unsigned long)sizeof abc);

Ok, you've got me! Why is the above modification necessary and why
could the original invoke undefined behavior?

What is the type expected by %d in a printf format?
What is the type of the value yielded by the sizeof operator?
What happens when the two types don't match?

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Fao, Sean]

Fao, Sean wrote:

Peter Shaggy Haywood wrote:

>># In terms of memory allocation, is there any difference between that # allocated for _xyz and _abc?

Add
printf("%d %d\n",sizeof(xy z),sizeof(abc)) ;
I would expect to see it print
1 2

I would expect the unexpected. When you invoke the wrath of the
undefined behaviour gods, you never really know what to expect. Well,
sometimes you can make a reasonable guess, but it can always go wrong
and do something you least expect.
Instead, try this:

printf("sizeof xyz = %lu, sizeof abc = %lu\n",
(unsigned long)sizeof xyz,
(unsigned long)sizeof abc);

Ok, you've got me! Why is the above modification necessary and why
could the original invoke undefined behavior?

Actually, let me see if I can figure this out for myself.

The sizeof operator results in something of type size_t, which I assume
on some implementations *could* be an unsigned long. If that's correct,
why not unsigned long long?

But this doesn't answer my question as to where the UD could come into
play. Obviously, the original code with a %d could not display any
number over INT_MAX; however, the result would still be defined (at
least I _think_ rolling over is defined)

Am I missing something?

--
Sean