This is the mail archive of the
mailing list for the GCC project.
addressof overloaded static member function bug
- To: egcs-bugs at cygnus dot com
- Subject: addressof overloaded static member function bug
- From: Nathan Sidwell <nathan at cs dot bris dot ac dot uk>
- Date: Mon, 10 Aug 1998 16:56:34 +0100
- Organization: Computer Science Dept, Bristol University
here's a bug present in the latest snapshot (1998/08/03) (I don't know
if it was in earlier snapshots too).
static int F1(void *);
static int F1(void *, int);
static void fn();
int (*f)(void *);
f = &F1;
f = &A::F1;
--begin session log
SunOS laie 5.5.1 Generic sun4u sparc SUNW,Ultra-1
nathan@laie:13>egcs-0803-g++ -v -c overload.ii
Reading specs from
gcc version egcs-2.91.53 19980803 (gcc2 ss-980609 experimental)
overload.ii -quiet -version -o /var/tmp/ccmivULs.s
GNU C++ version egcs-2.91.53 19980803 (gcc2 ss-980609 experimental)
(sparc-sun-solaris2.5.1) compiled by GNU C version 2.8.1.
overload.ii: In function `static void A::fn()':
overload.ii:13: assignment to `int (*)(void *)' from `int (*)(void *,
--end session log
If the declarations of the two A::F1 functions are swapped round, the
diagnostic does not occur!
The behavour I expect is that both A::F1(void *, int) and A::F1(void *)
are candidates, but the context of the &operator requires an int
(*)(void *) and therefore the latter function should be selected.
Notice that the explit selection of A::F1, rather than plain F1 does the
right thing, even though we're in a member of A and therefore there
should be no difference.
If my logic is flawed on this point, then it's still a bug, because the
declaration order of the two F1's should not affect the diagnostic.
Dr Nathan Sidwell :: Computer Science Department :: Bristol University
You can up the bandwidth, but you can't up the speed of light
firstname.lastname@example.org http://www.cs.bris.ac.uk/~nathan/ email@example.com