«

On 3/11/2011 9:45 PM, Stefan Ram wrote:
> (Stefan Ram) writes:
>> »the identifier is visible (i.e., can be used) only
>> within a region of program text called its scope.«,
>
> For example,
>
> struct a { int b; }; int main( void ){ b; }
>
> test.c:1: error: 'b' undeclared (first use in this function)
>
> , doesn't sound as if »b« would be visible in main.
>
> But, of course, gcc is just a compiler.
>
> But ISO/IEC 9899:1999 (E) even explains »visible«:
> »can be used« (see quotation above).
>
> »b« cannot be used in main above.
>
> We could add »a.« in front of »b« - but then it would
> be another program, so assertions about the scope in
> this other program would not be valid for the program
> above.

You're using "scope" for two notions that the Standard calls
"scope" and "name space." The identifier `b' is in scope everywhere
after its declaration -- including inside main() -- but has meaning
only in the name space of `struct a'. See 6.2.3.

--
Eric Sosman
d

"J. J. Farrell" <> writes:
> Keith Thompson wrote:
>> "Johannes Schaub (litb)" <> writes:
>>> Stefan Ram wrote:
>>>> "Johannes Schaub (litb)" <> writes:
>>>>> Does all that mean that struct members have a scope? Does the following
>>>>> program declare "x" to have file scope?
>>>>> struct A {
>>>>> int x;
>>>> Structure, union, and enumeration tags have scope that
>>>> begins just after the appearance of the tag in a type
>>>> specifier that declares the tag.
>>> Huh?
>>
>> That's a direct quotation from the standard, 6.2.1p7.
>
> Indeed, but what does it have to do with the question?

Not much; I didn't look closely enough at the context.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Eric Sosman wrote:

> On 3/11/2011 9:45 PM, Stefan Ram wrote:
>> (Stefan Ram) writes:
>>> »the identifier is visible (i.e., can be used) only
>>> within a region of program text called its scope.«,
>>
>> For example,
>>
>> struct a { int b; }; int main( void ){ b; }
>>
>> test.c:1: error: 'b' undeclared (first use in this function)
>>
>> , doesn't sound as if »b« would be visible in main.
>>
>> But, of course, gcc is just a compiler.
>>
>> But ISO/IEC 9899:1999 (E) even explains »visible«:
>> »can be used« (see quotation above).
>>
>> »b« cannot be used in main above.
>>
>> We could add »a.« in front of »b« - but then it would
>> be another program, so assertions about the scope in
>> this other program would not be valid for the program
>> above.
>
> You're using "scope" for two notions that the Standard calls
> "scope" and "name space." The identifier `b' is in scope everywhere
> after its declaration -- including inside main() -- but has meaning
> only in the name space of `struct a'. See 6.2.3.
>

The Standard introduces the concept of "namespaces" as merely a syntactic
construct to disambiguate uses, and not as a semantic entity that somehow
"contains" identifiers.

What does "in the namespace" mean?

Johannes Schaub (litb) wrote:

> Eric Sosman wrote:
>
>> On 3/11/2011 9:45 PM, Stefan Ram wrote:
>>> (Stefan Ram) writes:
>>>> »the identifier is visible (i.e., can be used) only
>>>> within a region of program text called its scope.«,
>>>
>>> For example,
>>>
>>> struct a { int b; }; int main( void ){ b; }
>>>
>>> test.c:1: error: 'b' undeclared (first use in this function)
>>>
>>> , doesn't sound as if »b« would be visible in main.
>>>
>>> But, of course, gcc is just a compiler.
>>>
>>> But ISO/IEC 9899:1999 (E) even explains »visible«:
>>> »can be used« (see quotation above).
>>>
>>> »b« cannot be used in main above.
>>>
>>> We could add »a.« in front of »b« - but then it would
>>> be another program, so assertions about the scope in
>>> this other program would not be valid for the program
>>> above.
>>
>> You're using "scope" for two notions that the Standard calls
>> "scope" and "name space." The identifier `b' is in scope everywhere
>> after its declaration -- including inside main() -- but has meaning
>> only in the name space of `struct a'. See 6.2.3.
>>
>
> The Standard introduces the concept of "namespaces" as merely a syntactic
> construct to disambiguate uses, and not as a semantic entity that somehow
> "contains" identifiers.
>
> What does "in the namespace" mean?

Ah I think I get this now. The name spaces divide a scope into multiple
sections.

Stefan Ram wrote:

> (Stefan Ram) writes:
>>»the identifier is visible (i.e., can be used) only
>>within a region of program text called its scope.«,
>
> For example,
>
> struct a { int b; }; int main( void ){ b; }
>
> test.c:1: error: 'b' undeclared (first use in this function)
>
> , doesn't sound as if »b« would be visible in main.
>
> But, of course, gcc is just a compiler.
>
> But ISO/IEC 9899:1999 (E) even explains »visible«:
> »can be used« (see quotation above).
>
> »b« cannot be used in main above.
>
> We could add »a.« in front of »b« - but then it would
> be another program, so assertions about the scope in
> this other program would not be valid for the program
> above.

No, "b" can be used in "main". But if you just do "b;", it will look into
the ordinary namespace for identifiers. You have to use an "a." or "a->" to
make it look into the struct-A members namespace of the global scope to use
"b" in main.

Just like you have to use "struct a" to use the identifier "a" in main,
which is in the tags namespace of the global scope.

Scott Fluhrer wrote:

>
> "Keith Thompson" <kst-> wrote in message
> news:...
>> (Stefan Ram) writes:
>>> Keith Thompson <kst-> writes:
>>>>>Stefan Ram wrote:
>>>>>>Structure, union, and enumeration tags have scope that
>>>>That's a direct quotation from the standard, 6.2.1p7.
>>>
>>> I was not careful enough: Actually, I wanted to write
>>> about members, not about tags.
>>>
>>> The scope of members is not given explicitly, it seems.
>>
>> It doesn't need to be. Note the last sentence:
>>
>> Structure, union, and enumeration tags have scope that begins
>> just after the appearance of the tag in a type speci?er that
>> declares the tag. Each enumeration constant has scope that
>> begins just after the appearance of its defining enumerator
>> in an enumerator list. Any other identifier has scope that
>> begins just after the completion of its declarator.
>>
>> I'm not sure whether the declarator in question is the declaration
>> of the member or of the struct or union. It might not matter;
>> I can't think of a legal way to use the name of a struct member
>> prior to the end of the struct declaration that contains it.
>
> Sounds like a challenge. How about:
>
>
> struct foo *x;
>
> struct foo {
> int a;
> char b[ sizeof x->a ];
> };
>
>
> gcc didn't like it; I haven't gone through the standard yet to see if
> there's any language to explicitly allow or disallow this.
>

Interesting. This seems to be allowed/not forbidden.

"Johannes Schaub (litb)" <> writes:

> Scott Fluhrer wrote:
>
>>
>> "Keith Thompson" <kst-> wrote in message
>> news:...
>>> (Stefan Ram) writes:
>>>> Keith Thompson <kst-> writes:
>>>>>>Stefan Ram wrote:
>>>>>>>Structure, union, and enumeration tags have scope that
>>>>>That's a direct quotation from the standard, 6.2.1p7.
>>>>
>>>> I was not careful enough: Actually, I wanted to write
>>>> about members, not about tags.
>>>>
>>>> The scope of members is not given explicitly, it seems.
>>>
>>> It doesn't need to be. Note the last sentence:
>>>
>>> Structure, union, and enumeration tags have scope that begins
>>> just after the appearance of the tag in a type speci?er that
>>> declares the tag. Each enumeration constant has scope that
>>> begins just after the appearance of its defining enumerator
>>> in an enumerator list. Any other identifier has scope that
>>> begins just after the completion of its declarator.
>>>
>>> I'm not sure whether the declarator in question is the declaration
>>> of the member or of the struct or union. It might not matter;
>>> I can't think of a legal way to use the name of a struct member
>>> prior to the end of the struct declaration that contains it.
>>
>> Sounds like a challenge. How about:
>>
>>
>> struct foo *x;
>>
>> struct foo {
>> int a;
>> char b[ sizeof x->a ];
>> };
>>
>>
>> gcc didn't like it; I haven't gone through the standard yet to see if
>> there's any language to explicitly allow or disallow this.
>>
>
> Interesting. This seems to be allowed/not forbidden.

Assuming there isn't any text that forbids it, surely
that's just an oversight in the Standard. The operators
'.' and '->' are expected to require complete types, no?

On Mar 12, 7:15*pm, Tim Rentsch <t...@alumni.caltech.edu> wrote:
> "Johannes Schaub (litb)" <schaub.johan...@googlemail.com> writes:
> > Scott Fluhrer wrote:
> >> Sounds like a challenge. *How about:
>
> >> struct foo *x;
>
> >> struct foo {
> >> * * int a;
> >> * * char b[ sizeof x->a ];
> >> };
>
> >> gcc didn't like it; I haven't gone through the standard yet to see if
> >> there's any language to explicitly allow or disallow this.
>
> > Interesting. This seems to be allowed/not forbidden.
>
> Assuming there isn't any text that forbids it, surely
> that's just an oversight in the Standard. *The operators
> '.' and '->' are expected to require complete types, no?

There is no reason why they should require a complete type, even
though many compilers reject the above code. Referring to a previously
declared member of a not yet completed structure type is possible in
theory, and at least one compiler permits it: OpenWatcom gives no
error, warning, or any other diagnostic for it.

Harald van Dijk wrote:

> On Mar 12, 7:15 pm, Tim Rentsch <t...@alumni.caltech.edu> wrote:
>> "Johannes Schaub (litb)" <schaub.johan...@googlemail.com> writes:
>> > Scott Fluhrer wrote:
>> >> Sounds like a challenge. How about:
>>
>> >> struct foo *x;
>>
>> >> struct foo {
>> >> int a;
>> >> char b[ sizeof x->a ];
>> >> };
>>
>> >> gcc didn't like it; I haven't gone through the standard yet to see if
>> >> there's any language to explicitly allow or disallow this.
>>
>> > Interesting. This seems to be allowed/not forbidden.
>>
>> Assuming there isn't any text that forbids it, surely
>> that's just an oversight in the Standard. The operators
>> '.' and '->' are expected to require complete types, no?
>
> There is no reason why they should require a complete type, even
> though many compilers reject the above code. Referring to a previously
> declared member of a not yet completed structure type is possible in
> theory, and at least one compiler permits it: OpenWatcom gives no
> error, warning, or any other diagnostic for it.

I filed a report on clang: http://llvm.org/bugs/show_bug.cgi?id=9471

Harald van Dij <> writes:

> On Mar 12, 7:15 pm, Tim Rentsch <t...@alumni.caltech.edu> wrote:
>> "Johannes Schaub (litb)" <schaub.johan...@googlemail.com> writes:
>> > Scott Fluhrer wrote:
>> >> Sounds like a challenge. How about:
>>
>> >> struct foo *x;
>>
>> >> struct foo {
>> >> int a;
>> >> char b[ sizeof x->a ];
>> >> };
>>
>> >> gcc didn't like it; I haven't gone through the standard yet to see if
>> >> there's any language to explicitly allow or disallow this.
>>
>> > Interesting. This seems to be allowed/not forbidden.
>>
>> Assuming there isn't any text that forbids it, surely
>> that's just an oversight in the Standard. The operators
>> '.' and '->' are expected to require complete types, no?
>
> There is no reason why they should require a complete type, even
> though many compilers reject the above code.

I meant 'require' in the sense of 'only guaranteed to be defined
for'.

> Referring to a previously
> declared member of a not yet completed structure type is possible in
> theory, and at least one compiler permits it: OpenWatcom gives no
> error, warning, or any other diagnostic for it.

And this behavior is reasonable, or at least permissible, if such
cases were specified as undefined behavior, which is how I expect
the Standard would specify it. So too is giving an error message
and refusing to proceed.