Bit Fields

[Tarique]

I have the program illustrating use of Bit-Fields:

#include<stdio.h>

struct DISK_REGISTER {
unsigned ready : 1;
unsigned error_occured : 1;
unsigned disk_spinning : 1;
unsigned write_protect : 1;
unsigned head_loaded : 1;
unsigned error_code : 8;
unsigned track : 9;
unsigned sector : 5;
unsigned command : 5;
};

int main(void)
{
struct DISK_REGISTER dr;

/*...no more code here ; just trying out...*/

return 0;
}

When i run it through a debugger( Visual C++ 08)
I get the following results :
Autos:
Name Value Type

ready 0 unsigned int
error_occured 0 unsigned int
disk_spinning 1 unsigned int
write_protect 1 unsigned int
head_loaded 0 unsigned int
error_code 102 unsigned int
track 102 unsigned int
sector 19 unsigned int
command 25 unsigned int

Can anyone please explain ,what the values mean?
I know that Bit-Fields are not-portable and probably the values
generated are compiler/system specific.
Further can anyone post pointers to any archive containing some more
examples?

 

[Walter Roberson]

I have the program illustrating use of Bit-Fields:

struct DISK_REGISTER {
unsigned ready : 1;
unsigned error_occured : 1;
unsigned disk_spinning : 1;
unsigned write_protect : 1;
unsigned head_loaded : 1;
unsigned error_code : 8;
unsigned track : 9;
unsigned sector : 5;
unsigned command : 5;
};

int main(void)
{
struct DISK_REGISTER dr;

/*...no more code here ; just trying out...*/

return 0;
}

When i run it through a debugger( Visual C++ 08)
I get the following results :
Autos:
Name Value Type

ready 0 unsigned int
error_occured 0 unsigned int
disk_spinning 1 unsigned int
write_protect 1 unsigned int
head_loaded 0 unsigned int
error_code 102 unsigned int
track 102 unsigned int
sector 19 unsigned int
command 25 unsigned int

Can anyone please explain ,what the values mean?

The values do not mean anything. You left dr uninitialized, so it
contains a random value. Glancing at the values, I -speculate- that
the memory location had previously been occupied by a pointer
with 'command' overlaying what used to be the most significant bits
of the pointer -- but that's pure speculation, and the value
could have been anything.

 

[Mark Bluemel]

I have the program illustrating use of Bit-Fields:

#include<stdio.h>

struct DISK_REGISTER {
unsigned ready : 1;
unsigned error_occured : 1;
unsigned disk_spinning : 1;
unsigned write_protect : 1;
unsigned head_loaded : 1;
unsigned error_code : 8;
unsigned track : 9;
unsigned sector : 5;
unsigned command : 5;
};

int main(void)
{
struct DISK_REGISTER dr;

/*...no more code here ; just trying out...*/

return 0;
}

When i run it through a debugger( Visual C++ 08)
I get the following results :
Autos:
Name Value Type

ready 0 unsigned int
error_occured 0 unsigned int
disk_spinning 1 unsigned int
write_protect 1 unsigned int
head_loaded 0 unsigned int
error_code 102 unsigned int
track 102 unsigned int
sector 19 unsigned int
command 25 unsigned int

Can anyone please explain ,what the values mean?

Absolutely nothing.

You've created the structure with automatic storage.

It is not guaranteed to be initialised to anything meaningful.

 

[vippstar]

I have the program illustrating use of Bit-Fields:

When i run it through a debugger( Visual C++ 08)
I get the following results :
Autos:
Name Value Type

ready 0 unsigned int
error_occured 0 unsigned int
disk_spinning 1 unsigned int
write_protect 1 unsigned int
head_loaded 0 unsigned int
error_code 102 unsigned int
track 102 unsigned int
sector 19 unsigned int
command 25 unsigned int

A debugs programs for a certain architecture and implementation.
C is beyond these. What you are inspecting is the values of
uninitialiazed objects.

I know that Bit-Fields are not-portable and probably the values

Bit-fields as a concept are portable. C89 has them.

Further can anyone post pointers to any archive containing some more
examples?

Regarding bit-fields?
look question 2.26 at the comp.lang.c FAQ
<http://c-faq.com/>

 

[Tarique]

Thank You.
I got the point.

 

[Martin Ambuhl]

I have the program illustrating use of Bit-Fields:

[The bit fields are irrelevant to your question]
[...]

int main(void)
{
struct DISK_REGISTER dr;

^^^^^^^^^^^^^^^^^^^^^^^
This is an uninitialized local variable. Its contents are indeterminate.

return 0;
}

[Tarique's question is about the values of dr as seen by his debugger]

Can anyone please explain ,what the values mean?

They mean nothing.
'dr' is an uninitialized local variable. Its contents are indeterminate.

I know that Bit-Fields are not-portable and probably the values
generated are compiler/system specific.

Bit-fields are portable. The manner in which they are stored becomes
important only when you write and read them, but that's true of _any_
variable written in one environment and read in another. Again,
bit-fields have *nothing* to do with your problem.

 

[Walter Roberson]

Bit-fields are portable. The manner in which they are stored becomes
important only when you write and read them, but that's true of _any_
variable written in one environment and read in another.

By "write and read them" I take it you mean "write and read them
to a stream (or file)". Whether that is what you meant is not
clear, but you might have perhaps not taken into account their
use in system interfaces. I don't -think- you mean the
vacuous statement that "if you just leave them sitting in memory
and do not use them in any way, then the manner in which they
are stored is not important."


The maximum bit-field size is not entirely specified. It
is a constraint violation if the number of bits specified exceeds
the number of bits in an "ordinary object" of the specified type,
int, signed int, unsigned int, or (C99) _Bool . However, the
underlying sizes of those objects is not fixed, so a bit-field
size of (say) 30 is valid on an implementation where int is 30 or more
bits, but not valid on an implementation where an int is only 16 bits.
For portability, one should thus restrict one's bitfields to 16 bits.
Unfortunately it is not uncommon for real interfaces to
be specified in terms of 32 bit words, and it is a nuisance to
portably synthesize a bit-field that crosses a 16 bit boundary.
The implementation is permitted to allocate any memory unit big
enough to hold the bitfield, so the implementation might choose
(for example) to pack a structure of bitfields inside a long
(say 32 bits) while not providing the tools to get the fields
where you want. For example, what does the following mean?

struct atest { unsigned int a:3; unsigned int b:16; unsigned int c:13 };

If the maximum memory unit size the implementation uses is 16 bits
(assuming the int is normally 16 bits), then this would be
(a, padding, b, c, padding) or (padding, a, b, padding, c) for
a total of 3 ints storage. But if the maximum memory unit size the
implementation uses is 32 bits (even through the int is normally 16),
or if int is 32 bits, then it would all get packed into 32 bits.
Stranger variations are possible for memory allocation unit
sizes from 20 to 32...


As you correctly point out (or imply), the padding differences are
A Problem for any kind of I/O stream interpreted by a different system,
but the variations in the maximum bit-field sizes make a code portability
difference, and the variations in the memory allocation unit together
with the variations in the maximum bit-field sizes can result in
having to piece together a structure literally bit-by-bit when
trying to do interoperability.