Re: c++/9750: Strange code in handling of COND? expressions in cp/call.c

Re: c++/9750: Strange code in handling of COND? expressions in cp/call.c

[bangerth]

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

Re: c++/9750: Strange code in handling of COND? expressions in cp/call.c

[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

c++/9750: Strange code in handling of COND? expressions in cp/call.c

[john.carter]

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