This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/30975] ptr to member func __delta is 0 if ptr declaration does not match function porototype
- From: "ingo dot donasch at L-3com dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 12 Mar 2007 14:32:06 -0000
- Subject: [Bug c++/30975] ptr to member func __delta is 0 if ptr declaration does not match function porototype
- References: <bug-30975-14163@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- 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