Xref: utzoo comp.std.c:4260 comp.windows.x:32428
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!usc!elroy.jpl.nasa.gov!ames!ucsd!mvb.saic.com!ncr-sd!iss-rb!tortuga!rns
From: rns@tortuga.SanDiego.NCR.COM (Rick Schubert)
Newsgroups: comp.std.c,comp.windows.x
Subject: Re: Initialization of automatics within loops
Message-ID: <1991Feb7.012702.11184@SanDiego.NCR.COM>
Date: 7 Feb 91 01:27:02 GMT
References: <1991Feb5.023809.389086@locus.com> <2293@inews.intel.com>
Sender: @SanDiego.NCR.COM
Reply-To: rns@tortuga.SanDiego.NCR.COM (Rick Schubert)
Organization: NCR Corporation, Rancho Bernardo
Lines: 34

In article <2293@inews.intel.com> bhoughto@hopi.intel.com (Blair P. Houghton) writes:
>In article <1991Feb5.023809.389086@locus.com> geoff@locus.com (Geoff Kuenning) writes:
>>(BTW, the
>>spec explicitly says that implementations get to decide whether automatics
>>are initialized upon jumps into a compound statement,

>No it doesn't.

>Ergo, jump to a labeled statement, and the initialization is skipped.

>Note that in:

>	/* just a block to scope-limit foo and bar */
>	{
>	    int foo = 3;
>mickle:
>	    int bar = 0111;
>
>	    foo *= bar;
>	}

>                         it is guaranteed that neither
>initialization is performed.

Someone else answered that the label is invalid here, so I'll proceed as
if the label were after the declarations.  In this case it CANNOT be
guaranteed that the initialization is NOT performed since there is no way
to tell (in a Standard Conforming program) that the initialization was or
was not done.  There is no way to test for an uninitialized value.  The only
thing that would be invalid for the implementation (compiler) to do would
be to evaluate an initialization expression that had side-effects that could
be tested for.

-- Rick Schubert (rns@tortuga.SanDiego.NCR.COM)