http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50282
--- Comment #4 from zhuli <imzhuli at vip dot qq.com> 2011-09-03 12:17:35 UTC --- yes, you are right. As an addition, compiling with -O2 might yield an warning, as you metioned. but i checked my env(32-bit) and used default compiler option, so i just simply assumed 4byte-object & 16byte-object share the same alignment. and as this is not the point of the issue, i didnt take much care about that. In fact, i seldom use such code, even to debug. Anyway, you comment is advisable, thanks. (In reply to comment #3) > (In reply to comment #2) > > I've never used any unint32_t tu hold any pointer-to-member, > > I just tested and find out the sizeof (pointer-to-member-function) is 16, > > then i used a pointer-to-uint32_t four times to dump the value of the > > pointer-to-member, 32bits by 32bits. > > > > According my understanding to the standard, this conversion should be > > valid, or > > there must be any valid way . > > The above violates C++ aliasing rules but would be supported by GCC as an > extension with -O[01] or -fno-strict-aliasing. The standard only allows > accessing the storage via a character type (thus, dump 16 individual bytes via > a char * pointer). > > > (In reply to comment #1) > > > uint32_t isn't big enough to hold a pointer-to-member value, and that > > > conversion isn't valid anyway
