c structure

[gsi]

Hi all,
I read the below question in a blog, and I am not sure if a portable way to do the same exists, or even a way to do this in C.

A function accepts an address of a structure member (not necessarily the first member) as its only argument. Given this is there a way to find out the start address of this structure object in memory. Assuming the hardware supports non aligned reads (implementation not important) and the compiler never pads the alignment bytes.

Please advice.

Thanks,
Gsi.

[Banfa]

Do you mean a pointer to any member of any structure or a pointer to a specific member of a specific structure?

In the first case there is no way to do it (that I can think of), in the second case then there are some no portable methods that would work (on some platforms).

[JosAH]

Do you mean a pointer to any member of any structure or a pointer to a specific member of a specific structure?

In the first case there is no way to do it (that I can think of), in the second case then there are some no portable methods that would work (on some platforms).

There's even a portable way to figure that out. There's the offsetof() macro in
<stddef.h>

kind regards,

Jos

[Banfa]

There's even a portable way to figure that out. There's the offsetof() macro in
<stddef.h>

Blimey your right but ...

I don't see how it can be there and be necessarily possible to implement on all conforming platforms. For instance in MSVC 2005 this is implemented as

#define offsetof(s,m) (size_t)&(((s *)0)->m)

But I would say that that was dereference on a NULL pointer and thus invoking undefined behaviour and that the cast from pointer to size_t has (at the very most) implementation defined behaviour.

And therefore an implementation could define there behaviours such that constructs like this do not work making the calculation impossible.

[JosAH]

Blimey your right but ...

I don't see how it can be there and be necessarily possible to implement on all conforming platforms. For instance in MSVC 2005 this is implemented as

#define offsetof(s,m) (size_t)&(((s *)0)->m)

But I would say that that was dereference on a NULL pointer and thus invoking undefined behaviour and that the cast from pointer to size_t has (at the very most) implementation defined behaviour.

And therefore an implementation could define there behaviours such that constructs like this do not work making the calculation impossible.

No, taking the address of a member of something doesn't involve any dereference.
Just simple address calculations can do the job. On systems where the null
pointer doesn't yield 0 (all bits zero) this macro doesn't do it of course so never
use this little gibberish yourself as portable code, i.e. use the macro instead.

kind regards,

Jos

[gsi]

Hi all,
Yes I was referring to what banfa said at the first place, a pointer to any member to any structure and thanks for the response.

No, taking the address of a member of something doesn't involve any dereference.
Just simple address calculations can do the job. On systems where the null
pointer doesn't yield 0 (all bits zero) this macro doesn't do it of course so never
use this little gibberish yourself as portable code, i.e. use the macro instead.

kind regards,

Jos

Just curious, If the null pointer in an implementation is not all bits zero, is it that the same is achieved via pointer arithmetic (may be the difference between the member and the start of structure, assuming machine is byte addressable and pointer converted to a char* beforehand).

Thanks in advance,
Gsi.

[weaknessforcats]

Just curious, If the null pointer in an implementation is not all bits zero,

What implementation does this?

If you have such a thing, it belongs in File 13.

BTW Jos: Does your nifty offsetof take into account vtbl pointers?

[gsi]

What implementation does this?
If you have such a thing, it belongs in File 13.

Diab Coldfire compiler
#define offsetof(s,memb) ((size_t)((char *)&((s *)0)->memb-(char *)0))

Didn't look at the compiler documentation though, I am assuming the null pointer for this implementation is not all bits zero. Please advice.

Thanks,
Gsi.

[JosAH]

What implementation does this?

If you have such a thing, it belongs in File 13.

BTW Jos: Does your nifty offsetof take into account vtbl pointers?

I had to look it up: Bjarne Stroustrup, the C++ programming language III, p.419:
you have to use the X::* syntax for a type X which isn't surprising because a
(virtual) method isn't 'physically' part of an object.

kind regards,

Jos

ps. I've never seen an architecture either where NULL wasn't a real all bits zero
address except for those silly 'small' models on PCs (the igored segment value
could be non-zero).

[gsi]

Hi,

BTW Jos: Does your nifty offsetof take into account vtbl pointers?

I suppose the offsetof() function macro extended to c++ is restricted only for "pod types" in which classes, more or less corresponds to the C concept of struct . I guess the previous versions of g++ did not have a c++ compliant macro defined, which pulled in the C compliant macro from <stddef.h> resulting in compile time errors. Recent g++ has it specialized for c++(using conditional preprocessors) but that too resticted for pod types.

Thanks,
Gsi.