Initialization of automatics within loops

Blair P. Houghton bhoughto at hopi.intel.com
Wed Feb 6 04:03:41 AEST 1991


In article <1991Feb5.023809.389086 at locus.com> geoff at locus.com (Geoff Kuenning) writes:
>The following little program demonstrates a problem found in the XSend()
>routine of XlibInt.c:
>
>	main ()
>	    {
>	    int i = 0;
>	    while (i < 3)
>		{
>		int j = 4;
>		printf ("i = %d, j = %d\n", i, j);
>		i++;
>		j++;
>		}
>	    }

Digression:  does anyone know where this style (having the
statements aligned with the braces that enclose them) came
from?  Before a few months ago I'd never seen it, and now
I've seen it in a dozen programs.  Who's fomenting this
bletcherous bowdlerization of my beloved C?

>I just checked the ANSI C spec on this, and found it unclear.  It is
>explicitly stated that automatics are initialized on every entry to a
>compound statement.  However, it is not made clear whether the construct:
>
>	while (<expression>)
>	    <statement>
>
>is considered to *re-enter* the compound statement every time or not.  My
>instinct says yes, the statement is re-entered, but obviously this
>interpretation is open to discussion.  In terms of usefulness, I could
>argue that either option is useful to programmers.

You answer your own question by your example.  A statement
is a statement is a statement, and the `while' has no clue
whether the statement is compound or simple; it merely
transfers control to it when the conditional-expression
evaluates nonzero, and takes back control when its end is
reached.  Any auto variables within the compound statement
can be reallocated as the implementation desires, and must
be reinitialized.

In the description of the compound statement:
"The initializers of objects that have automatic storage duration
are evaluated and the values are stored in the objects..."
(ANSI X3.159-1989, sec. 3.6.2, p. 77, ll. 4-5)

>What do people think the spec should do about this question?

At most, add the definition of the term "entry" to section
1.6, Definition of Terms; although that'd be a bit of overkill.
It might even be too much to ask for a footnote where that
use of the word appears (see below).

>(BTW, the
>spec explicitly says that implementations get to decide whether automatics
>are initialized upon jumps into a compound statement,

No it doesn't.

In sec. 3.1.2.4, Storage Duration of Objects, it explains
automatic storage, guarantees that the object will exist
whether you get into the statement through "...normal entry
to the block with which it is associated, or on a jump from
outside the block to a labeled statement in the block..."
(Ibid, sec. 3.1.2.4, p. 23, l. 14), then says:  "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 labeled statement"
(Ibid, ll. 16-18).

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

(Without a labeled statement, you can't get there from here).

Note that in:

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

	    foo *= bar;
	}

`mickle:' labels `foo *= bar;', which is a statement,
rather than `int bar = 0111;', which is a declaration, not
a statement.  So, despite the fact that `int bar = 0111;'
appears after `mickle:', it is guaranteed that neither
initialization is performed.

>I'm cross-posting to comp.windows.x so that X-Windows users will be made
>aware of a potential bug (the problem will show up only under certain
>very rare conditions, so it could be lurking in your system without your
>knowledge).

It (the character of the bug, not this particular bug)
does explain a few things I noticed about some commercial
implementations of the X-servers (from a company who shall
remain nameless), most notably the every-other-X-server bugs,
where you'd get odd alterations to X defaults on every
other time you reran the server (it dies and restarts with
every console-window logout).  The most common one was that
the screen-blanking would be reset to 0 seconds.  Very
annoying.  There were others involving massive destruction
of the X error logging file when one tried to get fonts
using certain _legal_ font-naming patterns.  It left many
megabytes of nulls in the error log, clogging the root
partition.  Then it dumped 2mb of X-server core in there,
too, which stuck despite the clog...

				--Blair
				  "Although their initials are DEC."



More information about the Comp.std.c mailing list