john@auspyr.UUCP (John Weald) (09/08/87)
What does the dpANSI standard have to say about the following?
The following program compiles (does not link of course) on 3b5 SVR2:
In the file foo.c:
main()
{
extern int foo;
foo++;
f();
}
f()
{
/* Same "foo" as above */
foo++;
}
K&R have this to say on the subject:
Page 76, section 4.5 "Scope Rules":
The scope of an external variable lasts from the point at which it
is declared in a source file to the end of that file. ...
(Some discussion about declarations deleted)
On the other hand, the lines
extern int sp;
extern double val[];
*declare* for the rest of the file that sp is an int and that
val is a double array.
Page 206, section 11.1 "Lexical Scope":
The lexical scope of identifiers declared in external definitions
persists from the definition through the end of the source file
in which they appear.
On our uVAX running VMS 4.5 (C v2.3) the variable "foo" only has scope
within the function block. It gives the message:
"foo" is not declared within the scope of this usage
The key words appear to be "though the end of the file."
Any comments?
John Weald, Austec, Inc. San Jose.
--
UUCP: {styx,imagen,dlb,gould,sci,altnet}!auspyr!johnhenry@utzoo.UUCP (Henry Spencer) (09/24/87)
Since nobody else has taken this one on... > The scope of an external variable lasts from the point at which it > is declared in a source file to the end of that file. ... Historically, the old C compilers took an "extern" declaration to be global even if it appeared inside a function. X3J11 (1 Oct 1986 draft) says that this is not the case, that the scope of an identifier declared within a function is the function body. (Roughly speaking.) The old behavior is mentioned in the appendix as a "common extension". > The lexical scope of identifiers declared in external definitions > persists from the definition through the end of the source file > in which they appear. This one isn't relevant, because "external definition" in K&Rspeak is a magic phrase with a specific meaning that doesn't apply here. -- "There's a lot more to do in space | Henry Spencer @ U of Toronto Zoology than sending people to Mars." --Bova | {allegra,ihnp4,decvax,utai}!utzoo!henry
cprodehl@cdp.UUCP (09/29/87)
Declaring a function (or prototype for that matter) inside block scope is now undefined behavior. This is from the latest X3J11 meeting in September. One is never sure how the resulting words will turn out until the new draft is available. In my opinion (my subconscious thinks in Pascal), such declarations should have block scope. Having it as undefined allows implementations to be true to hisorical usage. Courtney Prodehl
karl@haddock.ISC.COM (Karl Heuer) (09/30/87)
In article <69800001@cdp> cprodehl@cdp.UUCP writes: >Declaring a function (or prototype for that matter) inside block scope >is now [as of Sep87 X3J11 meeting] undefined behavior. If this is literally true, it seems a bit of overkill (though I could live with the restriction). In particular, if the function is never used outside of the block in which it's declared, the semantics are unambiguous and so I see no reason for it to be undefined behavior. (In fact, it's a useful documentation aid to give an object the smallest possible scope.) If, on the other hand, X3J11 is actually saying that something like f() { extern char *p(); ... } g() { ... p(); ... } produces undefined behavior, that seems perfectly reasonable. Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint
gwyn@brl-smoke.UUCP (10/01/87)
In article <69800001@cdp> cprodehl@cdp.UUCP writes: >Declaring a function (or prototype for that matter) inside block scope >is now undefined behavior. ... Hi, Courtney! My notes have it that it is undefined only if declared "static", not in general. { extern void *malloc(unsigned); /* okay */ void mysubr(void); /* okay */ static void another(void); /* undefined, may work or may not */ ... }
franka@mmintl.UUCP (Frank Adams) (10/02/87)
In article <69800001@cdp> cprodehl@cdp.UUCP writes: > >Declaring a function (or prototype for that matter) inside block scope >is now undefined behavior. I assume this means that: (1) references to the declared function name following the declaration inside the block are guaranteed to work. (2) the behavior for references outside the block scope is undefined. In other words, it not really the declaration inside the block whose behavior is undefined, but the reference to that declared object from outside the block. -- Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Ashton-Tate 52 Oakland Ave North E. Hartford, CT 06108