if a ptr to member function declaration differs from the prototype of the actual function being used, and the function is implemented in a subclass, and inherits from multiple base classes, the 4.x compiler generates a 0 for the __delta which cause the appl to crash when the function is called through the pointer with a wrong this ptr (pointing to the baseclass offset instead of the objects). problem was introduced with g++4.x, tested ok with g++3.4.
Created attachment 13117 [details] ref to C_good is ok, ref to C_bad crashes
Created attachment 13118 [details] output from: g++ -v -save-temps -g -Wall a.cpp
Well this is undefined code really. You are calling the function via the wrong type. If you do: c.t((FPTR)(FPTR1)&C::C_bad); And use it as a FPTR1, it works. FPTR1 is defined as: typedef void (B::*FPTR1)();
What exactly are you trying to achieve here: ------------- typedef void (B::*FPTR)(int); ... struct C : public A , public B { virtual void C_bad() { } }; c.t((FPTR)&C::C_bad); ------------------ Clearly, C::Cbad is a void function, but you assign it to a pointer to a function that takes an int. That can't possibly work. Indeed, if you let C_bad take an int, the segfault goes away. W.
Subject: RE: ptr to member func __delta is 0 if ptr declar ation does not match function porototype I know our code is wrong, but my point is that gcc34 generated correct code and gcc4x is not. A Gcc4x workaround that was mentioned to me is to double cast. The gcc4x compiler is NOT generating the offset to point into the correct subclass, it should either be compatible w/ gcc34 or better signal an error! I disagree with marking this bug report as "resolved invalid" but would accept a deferral because 2 workarounds exists and the code was bad anyways. Still I'm expecting the compiler to reject bad code if it can't generate code for it! ingo Ps. (we ran into that problem because someone added a parameter to the callback year ago w/o updating all the receiving function declarations #8-( ingo > -----Original Message----- > From: bangerth at dealii dot org [mailto:gcc-bugzilla@gcc.gnu.org] > Sent: Thursday, March 08, 2007 23:41 > To: Donasch, Ingo > Subject: [Bug c++/30975] ptr to member func __delta is 0 if > ptr declaration does not match function porototype > > > > > ------- Comment #4 from bangerth at dealii dot org > 2007-03-09 04:40 ------- What exactly are you trying to achieve here: > ------------- > typedef void (B::*FPTR)(int); > > ... > > struct C : public A , public B { > virtual void C_bad() { } > }; > > > c.t((FPTR)&C::C_bad); > ------------------ > Clearly, C::Cbad is a void function, but you assign it to a > pointer to a function that takes an int. That can't possibly > work. Indeed, if you let C_bad take an int, the segfault goes away. > > W. > > > -- > > bangerth at dealii dot org changed: > > What |Removed |Added > -------------------------------------------------------------- > -------------- > CC| |bangerth at > dealii dot org > Status|UNCONFIRMED |RESOLVED > Resolution| |INVALID > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30975 > > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. >
(In reply to comment #5) > I know our code is wrong, but my point is that gcc34 generated correct code > and gcc4x is not. No, it happened to produce code that happened to do what you thought it would. There is no way the compiler can know what you want if you cast the address of a function to a different type and then expect the compiler to figure out after the fact what it referred to. Just don't cast pointer types! > I disagree with marking this bug report as "resolved invalid" but would > accept a deferral because 2 workarounds exists and the code was bad anyways. > Still I'm expecting the compiler to reject bad code if it can't generate > code for it! What is the compiler supposed to do? You take the address of a function and cast it to a different pointer type. That's valid. You just mustn't use this pointer in any other way except casting it back to the original pointer type before you use it. You don't do that in this case, but at the point where the cast is missing, the compiler has no knowledge where the pointer it sees came from, so there's no way it can warn you here. (And the standard in fact recognizes this by saying that what you do invokes "undefined behavior" but that the compiler is not required to diagnose this.) There is really nothing a compiler can do in this situation. The fact that it worked before is by pure chance. Best Wolfgang