Zeljko Vrba wrote:
On Tue, Jun 05, 2007 at 04:35:16PM +0200, Ion Gaztañaga wrote:
I just realized about this just after sending my previous mail. SunCC seems to use the classical cfront approach encoding a pointer to member as offset + 1. So it seems that parent_from_member detection is correct for SunCC.
Slightly off-topic, but: do you know the background WHY did they decide to implement ptr-to-member as offset +1?
Because you need to represent a null pointer to data member. So they choose to represent a null pointer to member as 0 (which is a valid offset inside the object) and add 1 to the valid offset to represent a valid offset. The offset + 1 approach is shared by more implementations (CW for windows and Digital Mars, for example). This was the historical presentation C-front chose, so I think many compilers implement it like that because of this historical heritage. Other implementations used another encoding. For example, the Itanium C++ ABI says (http://www.codesourcery.com/cxx-abi/abi.html#member-pointers): "A pointer to data member is an offset from the base address of the class object containing it, represented as a ptrdiff_t. It has the size and alignment attributes of a ptrdiff_t. A NULL pointer is represented as -1."
I have tracked the conversion to here myself. I wondered whether this was a compiler bug, but the following simple program works, ie. it does NOT raise an assertion failure. I hope I managed to reproduce correctly the usage pattern of ptr-to-member..
[snip]
I'm kinda clueless as how to proceed from here. If it _is_ a genuine compiler bug, we need a more complex test-case, which I'm unable to produce myself (as I don't know how many intermediate instantiation steps there are in the intrusive library).
This seems a strange issue. I'll try to investigate it when I install the Sun compiler. Thanks for your effort! Ion