Results of duplicate-case-in-nested-switch survey

[chase at orc.olivetti.com]

Here's a summary of how different C compilers reacted to a program
(repeated at end of message) containing a duplicate case within a
nested switch statement.  I was prompted to do this because most
of the compilers accessible to me here either didn't report the error
or reported lots of bogus errors.  As it turns out, this appears to be
(usually) a PCC bug (should I be surprised?).  What looks like a
likely fix is also included.

(gcc 1.29 gets it right, gcc 1.32 is mute, SunOS 3.5 and 4.0 cc 
 each report two non-existent errors in addition to identifying the
 switch statement containing the duplicate case.)
----------------
RAMontante <bobmon at iuvax.cs.indiana.edu>
Turbo C v2.0 gets it "right", i.e. it agrees with gcc v1.29 that there
is a "duplicate case value in line 13" (not quite the exact wording).
----------------
Lee Fisher, Microsoft, leefi at microsof.UUCP, leefi%microsof at uw-beaver.MIL
Here are the results of using the Microsoft C compiler version 5.1:
  Microsoft C compiler 5.1 for DOS and OS/2, cl -W3:
  test.c(2) : warning C4103: 'foo' : function definition used as prototype
  test.c(13) : error C2053: case value 5 already used
----------------
Bill Smith, wsmith at cs.uiuc.edu
Encore's Multimax current OS's compiler says:
  "/tmp/wsmith/a.c", line 13: Duplicate case
----------------
vsi!friedl at uunet.UU.NET
AT&T's Issue 4 C compilers for the 3B2 do it wrong too.  I hear
from reliable sources that this has been fixed in the next
release.

and
Tony Hansen, hansen at pegasus.att.com
Unix System V release 3.2.1 on a 3B2 reports:
  "junk.c", line 15: duplicate case in switch, 5
  "junk.c", line 16: duplicate case in switch, 5
  "junk.c", line 17: duplicate case in switch, 0
----------------
John Woods, ames!harvard!wjh12!frog!john
Results for the Green Hills C compiler:
  Test.c:
  C-68000U 1.8.0 Copyright (c)1985,1986 Green Hills Software, Inc.
  "Test.c", line 13: Duplicate case
----------------
chemabs!chemabs!lwv27 at cis.ohio-state.edu (Larry W. Virden)
The following is the output from Ultrix 2.3's 2 c compilers.  The first
is based on a BSD compiler, though I was in 'system v' mode when executing
it - the second is the Ultrix VMS-compatible vcc compiler.
  UNIX16 (212) $ cc test.c
  "test.c", line 15: duplicate case in switch, 5
  "test.c", line 16: duplicate case in switch, 5
  "test.c", line 17: duplicate case in switch, 0
  UNIX16 (213) $ vcc test.c
  "test.c", line 13: %E-DUPCASE, Duplicate case label value "5".
  "test.c", line 19: %I-NOBJECT, No object file produced.
  "test.c", line 19: %I-SUMMARY, Completed with 1 error(s), 0 warning(s), and
                  1 informational messages.
  UNIX16 (214) $ uname -a
  ULTRIX-32 UNIX16 2.2 0 VAX
  UNIX16 (215) $ 
Note that the OS really is 2.3, even though uname says 2.2 ... sigh.
----------------
Michael Greim <greim%sbsvax.informatik.uni-saarland.dbp.de at RELAY.CS.NET>
SIEMENS PC-MX2 running SINIX v2.1 (SYS 3 derived):
  $ cc -c -W3 test16.c >& mist01
  c1:
  test16.c    7: [warning]:  flow between cases
  test16.c   10: [warning]:  flow between cases
  test16.c   13: [error]:    duplicate case: 5
  test16.c   14: [warning]:  flow between cases
  errors: 1, warnings: 3 in pass 1
  $
(-W3 turns on the warnings)
----------------
Chip Rosenthal     chip at vector.UUCP
Believe it or not ... Microsoft C (which is what the XENIX cc is) does:
    /tmp/foo.c(13) : error 53: case value 5 already used
----------------
Mark Grand of Ashton-Tate in Walnut Creek reports that the
Metaware CC compiler correctly identifies both lines involved
in the duplication.  (Anyone have a mail address for these people?)
----------------
and (already posted to netnews)
jeff at unh.UUCP (Jeffrey E. F. Friedl)
[offending CC's are PCC derivatives, here's how to fix it if you have
source]

I fixed mine this way (your filenames/function names may vary):
In cgram.y, function swend(), near the end is a sequence much like:

	if (there is a duplicate case) {
		report_error("duplicate case in switch, %d", value);
		return;
	}

	dosomethinghere();
	swp = swbeg-1;	/* this "pops" this switch from the switch-stack */
    } /* end of function */
	
Just copy the "swp=swbeg-1" line to after the error call.  All will be happy.
----------------

In summary, PCC derivatives get it wrong unless fixed, for GCC it
depends upon the release of the compiler (Doug Schmidt reports it is
fixed for the next (1.33) version of GCC, though 1.33 was not on prep
today when I looked just now), and every other compiler reported gets
it right, and (as a Bonus Treat) reports the offending line (not just
the offending switch statement).

(The test program:)
----------------
 1:	foo(i,j,k)   int i,j,k;
 2:	{
 3:	  int r = 0;
 4:	  switch (i)
 5:	    {
 6:	    case 1: r = i;
 7:	    case 2: switch (j)
 8:		{
 9:		case 3: r = j;
10:		case 4: switch (k)
11:		    {
12:		    case 5: break;
13:		    case 5: r = k; /* line 13, for reference */
14:		    case 6: break;
15:		    }
16:		}
17:	    }
18:	  return r;
19:	}
----------------

David Chase
Olivetti Research Center, Menlo Park