[Bug c++/30975] New: ptr to member func __delta is 0 if ptr declaration does not match function porototype

[Bug c++/30975] New: ptr to member func __delta is 0 if ptr declaration does not match function porototype

[ingo dot donasch at L-3com dot com]

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.


-- 
           Summary: ptr to member func __delta is 0 if ptr declaration does
                    not match function porototype
           Product: gcc
           Version: 4.1.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: ingo dot donasch at L-3com dot com
 GCC build triplet: Red Hat 4.1.1-51
  GCC host triplet: i386-redhat-linux
GCC target triplet: i386-redhat-linux


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30975

[Bug c++/30975] ptr to member func __delta is 0 if ptr declaration does not match function porototype

[ingo dot donasch at L-3com dot com]

------- Comment #1 from ingo dot donasch at L-3com dot com  2007-02-26 22:49 -------
Created an attachment (id=13117)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13117&action=view)
ref to C_good is ok, ref to C_bad crashes


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30975

[Bug c++/30975] ptr to member func __delta is 0 if ptr declaration does not match function porototype

[ingo dot donasch at L-3com dot com]

------- Comment #2 from ingo dot donasch at L-3com dot com  2007-02-26 22:51 -------
Created an attachment (id=13118)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13118&action=view)
output from: g++ -v -save-temps -g -Wall a.cpp


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30975

[Bug c++/30975] ptr to member func __delta is 0 if ptr declaration does not match function porototype

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2007-02-26 22:56 -------
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)();


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30975

[Bug c++/30975] ptr to member func __delta is 0 if ptr declaration does not match function porototype

[bangerth at dealii dot org]

------- 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

[Bug c++/30975] ptr to member func __delta is 0 if ptr declaration does not match function porototype

[ingo dot donasch at L-3com dot com]

------- Comment #5 from ingo dot donasch at L-3com dot com  2007-03-12 14:32 -------
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.
> 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30975

[Bug c++/30975] ptr to member func __delta is 0 if ptr declaration does not match function porototype

[bangerth at dealii dot org]

------- Comment #6 from bangerth at dealii dot org  2007-03-14 20:49 -------
(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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30975