[comp.std.c] Explanation, please!

davidsen@steinmetz.ge.com (William E. Davidsen Jr) (08/27/88)

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

walter@hpcllca.HP.COM (Walter Murray) (08/30/88)

William E. Davidsen Jr writes:

>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.
>
>Please tell me X3J11 didn't let this go unresolved for three
>years.

X3J11 didn't let this go unresolved.

From 3.1.2.4 Storage duration of objects:

   An object declared with no linkage and without the storage-class
   specifier static has automatic storage duration.  Storage is
   guaranteed to be reserved for a new instance of such an object on
   each normal entry into the block in which it is declared, or on a
   jump from outside the block to a label in the block or in an enclosed
   block.  If an initialization is specified for the value stored in
   the object, it is performed on each normal entry, but not if the
   block is entered by a jump to a label.

From A.5 Common Warnings:

   A block with initialization of an object that has automatic storage
   duration is jumped into.


Walter Murray