Actually, it defines the number of bits that the field (a.k.a. member) will occupy. If several fields with this :n specification will fit into a storage unit (generally, an int), then the compiler, at its discretion, and according to its own rules, can pack several of these fields into the same storage unit. Note that the ANSI standard leaves the rules of how these things are packed up to the "implementation" (that is, the compiler), so bit fields are specifically not portable. If you are going to back up things from one type of machine and restore them on another, do not even think of using bit fields as part of the back-up format.

SpiceWare is right, in that the number that follows the colon can be something other than one. The number determines how many bits to reserve in the storage unit for that field. The number cannot be greater that the size of the storage unit., so you can't say something like:

\nstruct big_ass\n{\n   unsigned int   super_long_int:128;\n};\n\n

Also, as someone else here said, you cannot take the address of a bit field; the compiler will not take kindly to such an attempt.

Finally, the field must still have a type. The ANSI standard requires the implementation to support all the integer types, but does not require the implementation to actually only reserve that sized storage unit for it. For example, the compiler is supposed to accept something like:

\nstruct its_OK\n{\n   unsigned char   a_field:4;\n   unsigned char   a_nother_field:5;\n};\n

But you cannot assume that the size of the structure is 2 bytes. (Since 9 bits have been allocated, the structure cannot fit into a single byte.) It can legally be as large as 8 bytes (on a 32-bit machine).

HTH...