Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: Case fall throughs
Message-ID: <7977@mimsy.UUCP>
Date: Fri, 14-Aug-87 02:13:12 EDT
Article-I.D.: mimsy.7977
Posted: Fri Aug 14 02:13:12 1987
Date-Received: Sat, 15-Aug-87 14:36:05 EDT
References: <2201@zeus.TEK.COM>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 61

In article <2201@zeus.TEK.COM> dant@tekla.TEK.COM (Dan Tilque) writes:
>... In those cases which have to have fall throughs, the /*FALLTHROUGH*/
>comment to lint (as suggested by Karl Heuer) would also be a good thing to
>put in even if lint didn't check for it.  It tells any maintenance
>programmer that the break was deliberately left out and is not the cause
>of the hard to track down bug.

That it was intentional does not indicate that it is not the cause
of some bug.  Or, put more simply, it may be intentional and wrong.
Still, I consider /*FALLTHROUGH*/ good programming practise.

On the topic of syntaxes to consider for a language with switches
with built-in breaks, another possibility (in addition to `case X,
Y, Z:' and a few other suggestions) is C's current syntax, but with
a semantic twist:  A built-in break occurs only *after* an executable
statement.  Hence

	switch (expr) {

	case A:
	case B:
		ab();

	case C:
		c();

	default:
		def();
	}

would do the `obvious thing'.

This has a disadvantage:

	switch (expr) {

	case A:
	#ifdef	somedef
		code;
	#endif

	case B:
		morecode;
		...
	}

Here case A would fall into case B iff `somedef' were not defined.

There are also `tricks' like

	case 1:
		{ int i; }	/* no exectable code? */

	case 2:
		...

Is there a fall through from case 1 to case 2?  Either way is
arguable, and the code is probably wrong anyway.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
Domain:	chris@mimsy.umd.edu	Path:	seismo|p el: Lbuilt