Xref: utzoo comp.lang.c:12112 comp.std.c:307
Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!uwmcsd1!leah!itsgw!steinmetz!davidsen
From: davidsen@steinmetz.ge.com (William E. Davidsen Jr)
Newsgroups: comp.lang.c,comp.std.c
Subject: Re: Explanation, please!
Message-ID: <11997@steinmetz.ge.com>
Date: 26 Aug 88 20:22:24 GMT
References: <638@paris.ICS.UCI.EDU>
Reply-To: davidsen@crdos1.UUCP (bill davidsen)
Followup-To: comp.lang.c
Organization: General Electric CRD, Schenectady, NY
Lines: 59

In article <638@paris.ICS.UCI.EDU> schmidt@bonnie.ics.uci.edu (Douglas C. Schmidt) writes:
| The following piece of wonderful obscurity comes from Stroustup's
| C++ Programming Language book, page 100:

[ a do loop within a switch, with cases all through the do loop ]

This does not seem to be clearly covered in the latest dpANS (section
3.6). The issue is if it is legal *and defined* to jump into a loop.
While a case label behaves just like any other label, it's not clear
what a jump into a loop implies, and I don't see that the existing
standard is any clearer on the topic than the discussion was three years
ago.

Consider:
	i = 15;
	if (j < 10) goto BadMove;

	/* more code here */

	do {
	  int i = 7;
	  int myvect[400];
	BadMove: /* entry into block */
	  myvect[300] = i;
	  if (j < 5) return i;
	} while (j-- > 302);

  There was a lot of discussion of this and I don't see a clarification
in the standard as it stands. I think there are several possibilities:
  1) it's not allowed
  2) it's allowed, but the initializations at the start of the
	block don't take place. What does this imply about the
	block local variables?
  3) it's allowed and the block local variables are allocated and
	initialized as you would expect.
  4) it's allowed but the results are implementation dependent.

  In all other cases entry into a block causes allocation of the block
local (auto) variables. Initialization is performed at the time of
allocation. By allowing entry at any point the expected behavior is
unspecified.

Suggestion:
  Forget (1), it's there for completeness. Pick any of 2-4 and add it to
the standard NOW, as an editorial change. We talked about this three
years ago, it can hardly be considered a recent issue. I would not
suggest (1) because it breaks a lot of existing code, but I would be
happy to see a (5) "you can't jump into a block with local variables."

  This is one of the rare times when I would like to be wrong, to be
told "oh, it's there in a footnote, you can, or you can't, and this is
what it does." If the action is implementation dependent then I
(personally) wouldn't use the feature, since I value portability
highly. Please tell me X3J11 didn't let this go unresolved for three
years.
-- 
	bill davidsen		(wedu@ge-crd.arpa)
  {uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me