Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: $Revision: 1.6.2.14 $; site umn-cs.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!ihnp4!stolaf!mmm!umn-cs!herndon
From: herndon@umn-cs.UUCP
Newsgroups: net.lang.c
Subject: Re: What happened to labels
Message-ID: <1700005@umn-cs.UUCP>
Date: Mon, 10-Mar-86 01:30:00 EST
Article-I.D.: umn-cs.1700005
Posted: Mon Mar 10 01:30:00 1986
Date-Received: Sat, 15-Mar-86 03:28:05 EST
References: <1420@brl-smok.UUCP>
Lines: 60
Nf-ID: #R:brl-smok:-142000:umn-cs:1700005:000:3296
Nf-From: umn-cs!herndon    Mar 10 00:30:00 1986


  [Gobble!]

  Ad-hominem arguments prove little.  Mr. Dietz (Dr. Paul Dietz?)
mentioned a problem to which he found an elegant solution in a
now unsupported feature of C.  I too have had similar problems and
think the statement to 'wise up' is very short-sighted.  Many
persons are capable of independent, creative thought and conjure
up elegant solutions to difficult problems.  These solutions often
violate common standards of 'structured programming'.  As classic
essays and novels often violate the standards of 'good english',
the most important thing about a program is not that it observe
the standards of 'structured programming'.  Manuals of style such
as 'The Elements of Style' by Strunk & White and 'The Elements of
Programming Style' by Kernighan & Plauger make this clear.
  A program, like prose, should convey its meaning to both the
machine and the programmer in the most direct and comprehensible
way possible.  This is not always best done by observing the strict
guidelines of structured programming.  On rare occasions, goto's
are the most elegant way to do things.  I will readily admit that
these situations are uncommon.
  The reasons usually given for avoiding the use of goto's in
computer programs are well-known.  These reasons are quite powerful,
and I strongly believe in them.  However, if a programmer were to
argue that "All labels are bad, so we should remove them from all
languages, including assembly code", we would think him ignorant.
  The C programming language used to permit arbitrary goto/label
operations through carelessness with types -- a label was simply
another value like an integer or pointer and could be manipulated
as such.  As C has acquired such add-ons as 'unions', type-coercion
operators, and stronger typing, a possibly useful operation has been
lost -- quite probably through carelessness.  Like the type 'void'
which was added as an afterthought and has bugs (try declaring
pointers to functions which return 'void' sometime with some of the
common compilers), the absolute restrictions laid down on label
usage also may be hasty.
  When C started acquiring stricter types, no special label type
was included for coercions or any other operations.  Thus one
cannot fill an array with labels to construct a jump table (even
though this can not cause any type conflicts) nor can one have
a variable of type label.  Constraints that all variables of
type label be initialized to a legitimate label, and that such
variables must be local and may not be passed as parameters might
cover the problems of goto's going to undefined locations.  Jump
tables are quite useful to those of us who write programs to
generate C programs -- and we might happily observe such constraints.
  I am sorry to write so much.  However, I think that C's restrictions
on labels have done little to stop the potential abuse of labels,
and has severely hampered those of us who would use them in an
organized and methodical fashion.  I would be gratified if the C
standards committee were to think over the present restrictions on
labels very carefully.

				Robert Herndon
				...!ihnp4!umn-cs!herndon
				herndon.umn-cs@csnet-relay.ARPA
				Dept. of Computer Science,
				Univ. of Minnesota,
				136 Lind Hall, 207 Church St. SE
				Minneapolis, MN  55455