Go Down

Topic: pointers, functions, bit fields, reference, struct.. (Read 1 time) previous topic - next topic


I guess an enum and a switch/case could do the job.

Decrements what variable?

struct member perhaps ?


An BTW, why do you pass a string as first argument ?

Code: [Select]
void editSetting(char *str, /* don't know what to put here */)


If it was my application, the first thing that I would do is evaluate that structure.
Code: [Select]
  unsigned int channel  : 4;
You want to use half the storage that an unsigned int allocates, to hold a value. Hmmm, looks like a byte to me, and no reason to mess with bit fields.

Paul, i think you're confusing nibbles (4bits) with bytes (8bits). believe me, it would have been nice if I had enough memory to do not mess with bit fields. my struct=32bits=8bytes. allocating all variables as int=7variables * 2bytes (int size) = 14bytes. i will have 3 user-selettable sets of settings, so 8*3=24bytes against 14*3=42.

I need to put together some of the most odd and obscure features of C.

None of these is obscure or odd, and any good C reference or tutorial will tell you all you need to know.

i meant, they're obscure or odd to me :)

The problem with bit-fields is that they may look like a neat way of mapping structures onto hardware registers or message formats, they're frequently not portable, because of endianness or memory alignment.

i think (even if the proper word is "hope") that memory alignment is not affected by my struct, because it is made to allocate exactly 4 bytes (as if it was a long integer)

An BTW, why do you pass a string as first argument ?
Code: [Select]
void editSetting(char *str, /* don't know what to put here */)

BTWs (and solutions as well) are welcomed! it's because i want the function to manage the display as well, so that string is what it will print. the use of this function to manage ALL the user-made parameter changes will ensure consistency among all the menu sections.


Feb 22, 2012, 03:15 am Last Edit: Feb 22, 2012, 03:20 am by pYro_65 Reason: 1
Until you know the correct amount of bits in a byte, You need to steer clear of bitfields.

32 bits is ony 4 bytes, not 8.

You need to re-consider the alignment statement you posted.

Here is a handy paragraph

c99 - Bit Fields.
An implementation may allocate any addressable storage unit large enough to hold a bitfield.
If enough space remains, a bit-field that immediately follows another bit-field in a structure shall be packed into adjacent bits of the same unit.
If insufficient space remains, whether a bit-field that does not fit is put into the next unit or overlaps adjacent units is implementation-defined.
The order of allocation of bit-fields within a unit (high-order to low-order or low-order to high-order) is implementation-defined.
The alignment of the addressable storage unit is unspecified.

Also note that the standard says that a "bit-field shall have a type that is a qualified or unqualified
version of int, unsigned int, or signed int", so having a bit-field in a char type is non-standard.

This explicitly makes bit-fields non portable, not even slightly.

Arduino is perfect for bit fields as they work on a 1 byte address boundary. But do not use the bit field with out extensive testing.

A standard class' data members are placed in memory in the order they are listed, a bit field can be backwards and there is no way to force its MSB/LSB ordering.

However by allocating contiguous memory using a 32 bit integer
then casting to your bit field ensures the bit field is mapped to memory.


Paul, i think you're confusing nibbles (4bits) with bytes (8bits).

Yes, I got the size wrong. Pre-coffee answers are not always the best.

Go Up