🚀 go-pugleaf

dpANS says the expression in ``_s_w_i_t_c_h (expression)''
must be an integer valued expression.  Any chance of
getting this changed ``must be an integer or ptr valued
expression''?  The current restriction forces one to use
the messier and longer sequence of ``if..then..else if
...'' for pointers.  That is, instead of

	switch (ptr)
	{
	case PTR1:
		foo; bar1; break;
	case PTR2: case PTR3:
		foo; bar2; break;
	default:
		foo; barx; break;
	}

the following must be used:

	if (ptr == PTR1) {
		foo; bar1;
	} else if (ptr == PTR2 || ptr == PTR3) {
		foo; bar2;
	} else {
		foo; barx;
	}

The latter can get quite unwieldy when a ptr has to be
compared with a lot of constants and each case is non-
simple.  Worse, if you wanted to fallthrough one case to
another after doing some work, you'd have to use a
spaghetti of gotos -- hopefully, no one does this.

Note that the switch stmt can be used by casting the ptr
to a long or an int, but I don't know if this is safe on
all architectures -- (casts) should be avoided where
possible.

The change in specification should be to state that a
_s_w_i_t_c_h expression must be either an int or a ptr, and
the _c_a_s_e const expression must be compatible with it.

Except for the stupid default fallthrough, a switch stmt
can be thought of as equivalent to a sequence of
``if..then..else if ... '', where each if-expr is an
equality comparison and anything that can be compared
for equality should be allowed as a switch expressio.

I noticed this when a dpANS compiler we use recently
tightened its type system.  As a resule some switch code
to deal with SIG_DFL, SIG_IGN etc. wouldn't compile
anymore (and I hate to change other people's sensible
and clear code).

Could it be that even though K&R1 forbade mixing ints
with ptrs and specified that only integer expression be
used in a switch expression, all old compilers continued
to treat the switch expression `sensibly' AND _somehow_
the committee overlooked this?

-- Bakul Shah <..!{ucbvax,sun,uunet}!amdcad!light!bvs>