🚀 go-pugleaf

In article <77210008@hpclscu.HP.COM> shankar@hpclscu.HP.COM (Shankar Unni) writes:
>Does a declaration in the middle of a { } block start a new scope? A new
>block?
>
>Consider the following example:
>
>   void foo()
>   {
>       extern void bar();	// decl
>       int i;			// decl
>       
>       i = 1;			// statement
>
>       extern void bar(int);	// decl: overloaded with above bar()?
>       
>       bar();			// statement: legal?
>   }
>
>Is the second declaration of bar ("extern void bar(int)") considered an
>overloaded variant of the parameterless bar(), or the start of a new scope
>(so that it hides the parameterless bar())?

Per E&S (section 6.3), a block is equivalent to a compound statement,
which is a statement-list. A statement-list is then composed of a
statement, or a statement-list followed by a statement. It is explicitly
stated at end of the section that a declaration _is_ a statement (section
6.7). And, in section 6.0, E&S explicitly states that "... in C++ 
declarations need not be placed before statements in a block, but can be 
introduced where first needed".

>Cfront 2.1 (and 2.0) apparently seems to make the latter interpretation,
>and complains about the parameterless call to bar().

Somehow this must be some sort of scope definition bug in cfront2.0
(AT&T has some problem with our cfront2.1 upgrade paperwork, so I don't 
have 2.1 to test against yet). If you move the second extern void bar 
declaration so that it is before the "i = 1;" statement, the code compiles! 
So cfront2.0 must be tacitly assuming that the second bar declaration _does_
start a new block, which is (at least to me) in conflict with the excerpts 
of E&S section 6 quoted above.

>The ARM (sections 7, 10.4, etc) is suitably obscure on this point. They do
>mention that declarations hide other declarations of the same identifier in
>"an outer block", but it's unclear as to how that is to be applied in the
>above situation.

By how I read E&S, this should all be in the same block, which means that
the overriding argument should not apply here.


Cynthia Ellis
Tektronix, Inc.
ellis@tekcrl.LABS.TEK.COM
(503) 627-6680