Finding the "address" of a bitfield

[homer_3]

So I obviously can't take the address of a bitfield, but is there a way to get the address of the field holding the bitfield? What I'm trying to do is find the address of the parent field of a bitfield in a class. For example

class Foo
{
public:
  int a;
  int b : 4;
  int c : 28;
};

void func()
{
  Foo foo;

  printf("%u\n", offsetof(Foo, c));
}

My goal is to get the offset address of the int storing c in class Foo. But offsetof uses the address of c, so I get a compile error since c is a bitfield. What I wanted as output from the above would be "4", since an int is 4 bytes (on my system). So the int holding both b & c starts 4 bytes from the start of the Foo class.

Is there any way to do this in c/c++?

[laserlight]

Out of curiosity, but why do you want to do this?

[rcgldr]

Is there any way to do this in c/c++?

Try using a union of unsigned integer(s) and bit fields.

[homer_3]

Out of curiosity, but why do you want to do this?

It'd due to general limitations. I need a way to output some numeric identifier for the class field. The offset from the start of the class seems like the best identifier to me.

Try using a union of unsigned integer(s) and bit fields.

Would be nice, but I can't change the code.

[Salem]

> Would be nice, but I can't change the code.
Any other pertinent information you'd like to share with us, before we try and think up some other ideas for you to reject.

[homer_3]

> Would be nice, but I can't change the code.
Any other pertinent information you'd like to share with us, before we try and think up some other ideas for you to reject.

Wow, you're upset. I did give a very specific example. Why would there be an expectation that the example could be changed in order to solve the problem?

[smokeyangel]

Seems quite an odd thing to want. So odd that I'm not convinced you really want it

It's an interesting question though, and I think I thought of a horrible way to do it. If you can't make a proper union, you can fake it, provided your containers are all the same size and it is really the container offset that you want.

• Create an object of type foo
• Point an int* at it
• Adjust a field, using the foo pointer
• Examine the elements of the int* array (you can use sizeof(foo) to get an upper limit on the number of elements) and see which one has changed (initialise it all to a known value like 0 to start with)

You can use sizeof(foo) to work out the number of elements in the array. You can wrap it all up in a horrible macro so you have your own sort of offsetof-alike cheat.

If you have different sized containers.... that could be fun. You could use a char* array to get the byte offset then relate that back to the original type somehow. If you have typeof() on your compiler (e.g. GCC) you could use that to get the type.

[smokeyangel]

I did it like this:

unsigned get_offset(void * f)
{
   int * arr = (int*)f;
   int i = 0;
   while (!arr[i])
      i++;  
   return i * sizeof(int);  
}

#define GetOffset(str, field) ({str f; memset(&f, 0, sizeof(f)); f.field = 1; get_offset(&f);})

Called like:

  printf("\nb: %u\n", GetOffset(Foo, b) );

I think that's the first time I've ever used a void* and meant it
I shouldn't have called it GetOffset since that's not what it does.... GetIntSizedBitfieldContainerOffset would be better but depends how much you like typing.
I could have put the whole thing in a macro, but writing many lines of straight code inside a macro always feels wrong to me.

[Salem]

> Wow, you're upset. I did give a very specific example. Why would there be an expectation that the example could be changed in order to solve the problem?
1. You already knew that you can't take the address of a bit-field.
2. You asked "Is there any way to do this in c/c++?"

Now when people say "any way", that usually means that nothing is off the table as far as solutions go.

I'm not upset, but you should apologise to rcgldr for wasting their time on what would otherwise be a fine suggestion.

Oh, and just to keep things interesting, there's a bug in smokeyangel's solution (very subtle one, it'll be interesting to see who can spot it).

[smokeyangel]

Bug? I have no idea!

I can think of a number of things that are bad about it:

• The types are a disaster waiting to happen (using signed int, and using 32-bit types at all). I should have used size_t, and cout for the printing, since C++ doesn't have a format specifier for size_t.
• The macro is horribly illegal. GCC says "ISO C++ forbids braced-groups within expressions" with -pedantic. I'm not thrilled about this use of a macro, even if there's a legal way. It seems a lot of code to spatter all around the place. I don't know any other way to generate "foo->a" from the name 'a', but wonder if there's a way to not have so much live inside the macro.
• The code assumes it can safely access int pointers at the address of foo, which might not be true (e.g. Foo is packed/unaigned). Should use a char* and figure out the int container from that

But they're not a specific "bug", so I guess you're thinking of something else. Curious!

[King Mir]

I think you want f.field = ~0 (aka -1) so that it finds where foo begins, not ends.

[grumpy]

What I wanted as output from the above would be "4", since an int is 4 bytes (on my system). So the int holding both b & c starts 4 bytes from the start of the Foo class.

That is not necessarily true, even if an int is 4 bytes on your system.

If you want to be able to refer to specific bits, better to use bitwise operations rather than bitfields. The layout of bitfields is implementation defined, and there are more possibilities in your code than bundling b and c into a single 4-byte word, even if int is 4 bytes on your system. There is, for example, nothing preventing the compiler from packing fields b and c into separate words. The fact they can potentially fit does not mean the compiler is required to fit them in.

With bitwise operations you can explicitly control the packing of bits.

[smokeyangel]

I think you want f.field = ~0 (aka -1) so that it finds where foo begins, not ends.

Aha, nice spot. I hadn't realised just how "implementation defined" they were! I had a set of rules in my head from a specific platform (where a bitfield can't staddle two units).

Bit-fields are packed into some
addressable allocation unit. [ Note: Bit-fields straddle allocation units on some machines and not on others.
Bit-fields are assigned right-to-left on some machines, left-to-right on others. — end note ]

Yeesh. "Do whatever you want"....

This thread has made me ask "why on earth would anyone ever use these things?". Googling seems to show that people do use bitfields in the hope of getting precise bit layours, and amazingingly live to tell the tale. I suppose such programs are already extremely platform and compiler dependent, so portability is a non issue. In that case relying on implementation defined behaviour is ok.

OP: You wrote:

I need a way to output some numeric identifier for the class field. The offset from the start of the class seems like the best identifier to me.

These not-unique "numeric identifiers" have me puzzled. Could you explain what they're used for?

[homer_3]

There is, for example, nothing preventing the compiler from packing fields b and c into separate words. The fact they can potentially fit does not mean the compiler is required to fit them in.

Why do they have to make my life so hard! Thanks though, good info to know.

It looks like smokey has the best solution. I think I can work with that, thanks!

[Salem]

> f.field = 1
The specific bug I was thinking of is the case where the field in question is say 'signed int a:1'.
Being signed, and with only 1 bit, the only valid values that can be stored are 0 and -1, so technically assigning 1 is a numeric overflow.

King Mir's approach nicely solves a couple of issues.