Xref: utzoo comp.std.c:4244 comp.windows.x:32310 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!olivea!orc!inews!hopi!bhoughto From: bhoughto@hopi.intel.com (Blair P. Houghton) Newsgroups: comp.std.c,comp.windows.x Subject: Re: Initialization of automatics within loops Message-ID: <2293@inews.intel.com> Date: 5 Feb 91 17:03:41 GMT References: <1991Feb5.023809.389086@locus.com> Sender: news@inews.intel.com Organization: Intel Corp, Chandler, AZ Lines: 115 In article <1991Feb5.023809.389086@locus.com> geoff@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 () > > >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."