public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* c++/9750: Strange code in handling of COND? expressions in cp/call.c
@ 2003-02-19 2:26 john.carter
0 siblings, 0 replies; 3+ messages in thread
From: john.carter @ 2003-02-19 2:26 UTC (permalink / raw)
To: gcc-gnats
>Number: 9750
>Category: c++
>Synopsis: Strange code in handling of COND? expressions in cp/call.c
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: unassigned
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Wed Feb 19 02:26:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator: john.carter@tait.co.nz
>Release: gcc-3.2.2
>Organization:
>Environment:
All.
>Description:
This code is in gcc-3.2.2/gcc/cp/call.c line 1961
/* Otherwise, the types should be pointers. */
if (!(TREE_CODE (type1) == POINTER_TYPE
|| TYPE_PTRMEM_P (type1)
|| TYPE_PTRMEMFUNC_P (type1))
|| !(TREE_CODE (type2) == POINTER_TYPE
|| TYPE_PTRMEM_P (type2)
|| TYPE_PTRMEMFUNC_P (type2)))
return candidates;
/* We don't check that the two types are the same; the logic
below will actually create two candidates; one in which both
parameter types are TYPE1, and one in which both parameter
types are TYPE2. */
break;
/* These arguments do not make for a legal overloaded operator. */
return candidates;
Note that the indentation for the "break" statement suggests that someone expects it was part of an "if" statement perhaps. And the "return candidates" code is now unreachable.
Probably not a bug, but a bit confuzzling.
>How-To-Repeat:
antic distributed as part of the jlint package found this.
>Fix:
Guess. Correct the indentation on the break and remove the "return candidates". This will make no difference to the code, but someone that grok's this code should have a look before this is done.
There are many instances of code like this...
case BLOO :
if (blah)
break;
case FLOO :
if (flah)
break;
Perhaps the author meant BLOO handling to fall through to FLOO handling. Perhaps he didn't. It would be nice to have a comment /* Fall through */ when it is known that this is meant to happen.
>Release-Note:
>Audit-Trail:
>Unformatted:
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: c++/9750: Strange code in handling of COND? expressions in cp/call.c
@ 2003-03-06 20:10 mmitchel
0 siblings, 0 replies; 3+ messages in thread
From: mmitchel @ 2003-03-06 20:10 UTC (permalink / raw)
To: gcc-bugs, gcc-prs, john.carter, mmitchel
Synopsis: Strange code in handling of COND? expressions in cp/call.c
State-Changed-From-To: analyzed->closed
State-Changed-By: mmitchel
State-Changed-When: Thu Mar 6 20:10:03 2003
State-Changed-Why:
Fixed in GCC 3.4.
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9750
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: c++/9750: Strange code in handling of COND? expressions in cp/call.c
@ 2003-02-19 2:50 bangerth
0 siblings, 0 replies; 3+ messages in thread
From: bangerth @ 2003-02-19 2:50 UTC (permalink / raw)
To: gcc-bugs, gcc-prs, john.carter, mmitchel, nobody
Synopsis: Strange code in handling of COND? expressions in cp/call.c
Responsible-Changed-From-To: unassigned->mmitchel
Responsible-Changed-By: bangerth
Responsible-Changed-When: Wed Feb 19 02:50:19 2003
Responsible-Changed-Why:
Inserted the comment before the dubious part of the code as
well as most of the other stuff around.
State-Changed-From-To: open->analyzed
State-Changed-By: bangerth
State-Changed-When: Wed Feb 19 02:50:19 2003
State-Changed-Why:
True -- good spot! The code is still in present CVS.
CVS annotate shows for this part:
1.1 (law 11-Aug-97): return candidates;
1.152 (mmitchel 26-Jul-99):
1.152 (mmitchel 26-Jul-99): /* We don't check that the two types are the same; the logic
1.152 (mmitchel 26-Jul-99): below will actually create two candidates; one in which both
1.152 (mmitchel 26-Jul-99): parameter types are TYPE1, and one in which both parameter
1.152 (mmitchel 26-Jul-99): types are TYPE2. */
1.1 (law 11-Aug-97): break;
1.152 (mmitchel 26-Jul-99):
1.329 (mrs 09-Aug-02): /* These arguments do not make for a valid overloaded operator. */
1.1 (law 11-Aug-97): return candidates;
So I guess Mark might know best what should come after the
comment he inserted. Probably something easy enough to
check.
If you have more of this dubious stuff, let us know!
Thanks
Wolfgang
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9750
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2003-03-06 20:10 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-02-19 2:26 c++/9750: Strange code in handling of COND? expressions in cp/call.c john.carter
2003-02-19 2:50 bangerth
2003-03-06 20:10 mmitchel
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).