Bit-Fields in C.

[Mr.Lnx]

Hello. I have some queries about bit fields :

Let's look at how the MS-DOS operating system stores the date at which a file created or modified?!

struct file_date {

    unsigned int day : 5;   // 5 is the length of this member in bits
    unsigned int month: 4;
    unsigned int year : 7;
};

The book that I am reading said that storing these numbers as normal integers would waste space of memory. My queries has to do with the memory layout. I have read that the size of a structure is not the sum of the size of its members because of the CPU allignment, is that true? and if it is why we are talking about memory economy? if we create bit fields like here? how we know that we save some memory space?

What is the usage of unnamed bit field? What is the "padding" ?

Assuming that we have the following union :

union int_date {
  unsigned short i;
  struct file_date fd;
};

What is the size of this union? It is the biggest member in size but can we know this in advance due to allignment on the structure?

[GReaper]

The int and unsigned int types have the size of the system word. This is two bytes (the same as short and unsigned short) in MS-DOS and 16-bit versions of Windows, and 4 bytes in 32-bit operating systems. However, portable code should not depend on the size of int.

Therefore, the size of and the alignment of the bit-field will most likely be 2 in MS-DOS. For the same reason, the union will most likely be 2 bytes in size.

Bit-fields have little to do with memory alignment. The compiler, when you try to access a bit-field value, does the shifting and masking of the requested bits, in order to seem like you're operating using discrete values.

[stahta01]

Does anyone but me think using Bit-Fields is often a case of premature optimization?

Edit: In the MS-DOS days it was valid optimization because of the 640K memory limit.

Tim S.

[Romme]

Plus the way the FAT was builded up, You did not have much room for file name, attributes, date and so on.

LNX, to save memory, let the int contain the date as on disk instead of in the struct

unsigned int date;

date = day * 0xf800 + month * 0x0780 + year;

No struct, no this not that only one int.

[Click_here]

Plus the way the FAT was builded up, You did not have much room for file name, attributes, date and so on.

LNX, to save memory, let the int contain the date as on disk instead of in the struct

unsigned int date;

date = day * 0xf800 + month * 0x0780 + year;

No struct, no this not that only one int.

Did you mean to use bitwise "and" instead of multiplication?

i.e.

date = (day & 0xf800) + (month & 0x0780) + year;

[edit]
And maybe some bit shifting?
[/edit]

[Romme]

No actually multiplications.