Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #112045 > unrolled thread

Scope of identifiers

Back to article view | Back to comp.lang.c

Contents

  Scope of identifiers Steve Keller <keller@no.invalid> - 2017-06-12 18:08 +0200
    Re: Scope of identifiers "James R. Kuyper" <jameskuyper@verizon.net> - 2017-06-12 12:22 -0400
      Re: Scope of identifiers Keith Thompson <kst-u@mib.org> - 2017-06-12 09:39 -0700
    Re: Scope of identifiers Keith Thompson <kst-u@mib.org> - 2017-06-12 09:38 -0700
      Re: Scope of identifiers "James R. Kuyper" <jameskuyper@verizon.net> - 2017-06-12 14:41 -0400
        Re: Scope of identifiers Keith Thompson <kst-u@mib.org> - 2017-06-12 12:39 -0700
          Re: Scope of identifiers "James R. Kuyper" <jameskuyper@verizon.net> - 2017-06-12 15:53 -0400
            Re: Scope of identifiers Keith Thompson <kst-u@mib.org> - 2017-06-12 13:19 -0700
              Re: Scope of identifiers David Kleinecke <dkleinecke@gmail.com> - 2017-06-13 11:01 -0700
                Re: Scope of identifiers jameskuyper@verizon.net - 2017-06-13 11:25 -0700
                Re: Scope of identifiers Keith Thompson <kst-u@mib.org> - 2017-06-13 12:16 -0700
                  Re: Scope of identifiers David Kleinecke <dkleinecke@gmail.com> - 2017-06-13 21:02 -0700
                    Re: Scope of identifiers Ian Collins <ian-news@hotmail.com> - 2017-06-14 21:53 +1200
                    Re: Scope of identifiers supercat@casperkitty.com - 2017-06-14 08:10 -0700
                      Re: Scope of identifiers Keith Thompson <kst-u@mib.org> - 2017-06-14 09:19 -0700
                        Re: Scope of identifiers supercat@casperkitty.com - 2017-06-14 10:14 -0700
                    Re: Scope of identifiers Keith Thompson <kst-u@mib.org> - 2017-06-14 09:12 -0700
    Re: Scope of identifiers Robert Wessel <robertwessel2@yahoo.com> - 2017-06-12 13:02 -0500

#112045 — Scope of identifiers

While reading again in the standard about declarations and (tentative)
definitions, and linkage, I also read about scope of identifiers and
was confused:

The standard says in 6.2.1p6 that "two identifiers have the same
scope if and only if their scopes terminate at the same point."

That section also talks about the beginning of a scope in 6.2.1p7
and says that except for structure, union, and enumeration tags "any
other identifier has scope that begins just after the completion of
its declarator."

But what does that mean in case of

$ nl -ba foo.c
     1  int a;
     2  int *p = &a;
     3  
     4  int foo() {
     5      int foo = 0;
     6      int bar = foo + 1;
     7  }

Paragraph 6.2.1p6 says that 'a' and 'p' have the same scope although
paragraph 6.2.1p7 says that the scope of 'a' begins at the end of line 1
while the scope of 'p' begins in line 2 right before the '='.  IMO,
that looks contradicting, unless you also define that two scopes can
be the same although they begin at different points.  Analoguous for
foo and bar.

Can someone explan this to me?

Steve

[toc] | [next] | [standalone]

#112049

On 06/12/2017 12:08 PM, Steve Keller wrote:
> While reading again in the standard about declarations and (tentative)
> definitions, and linkage, I also read about scope of identifiers and
> was confused:
>
> The standard says in 6.2.1p6 that "two identifiers have the same
> scope if and only if their scopes terminate at the same point."
>
> That section also talks about the beginning of a scope in 6.2.1p7
> and says that except for structure, union, and enumeration tags "any
> other identifier has scope that begins just after the completion of
> its declarator."
>
> But what does that mean in case of
>
> $ nl -ba foo.c
>      1  int a;
>      2  int *p = &a;
>      3
>      4  int foo() {
>      5      int foo = 0;
>      6      int bar = foo + 1;
>      7  }
>
> Paragraph 6.2.1p6 says that 'a' and 'p' have the same scope although
> paragraph 6.2.1p7 says that the scope of 'a' begins at the end of line 1
> while the scope of 'p' begins in line 2 right before the '='.

Correct.

> ... IMO,
> that looks contradicting, unless you also define that two scopes can
> be the same although they begin at different points.

Yes, which is why the standard say so explicitly, as in 6.2.1p6, so that 
people don't make the mistake of thinking that scopes that begin at 
different locations are different scopes.

If it weren't for that rule, no two identifiers would ever have the same 
scope, because every identifier has a scope that begins in a different 
location.  Keep in mind what the standard says about "same scope", and 
try to figure out how you would have to re-write the following clauses 
if every identifier lived in it's own unique scope:

"An identifier declared in different scopes or in the same scope more 
than once can be made to refer to the same object or function by a 
process called linkage." (6.2.2p1)

"A structure or union type of unknown content (as described in 6.7.2.3) 
is an incomplete type. It is completed, for all declarations of that 
type, by declaring the same structure or union tag with its defining 
content later in the same scope." (6.2.5p22)

"If an identifier has no linkage, there shall be no more than one 
declaration of the identifier (in a declarator or type specifier) with 
the same scope and in the same name space, ..." (6.7p3)

"All declarations in the same scope that refer to the same object or 
function shall specify compatible types." (6.7p4)

"All declarations of structure, union, or enumerated types that have the 
same scope and use the same tag declare the same type." (6.7.2.3p4)

[toc] | [prev] | [next] | [standalone]

#112056

"James R. Kuyper" <jameskuyper@verizon.net> writes:
[...]
> Yes, which is why the standard say so explicitly, as in 6.2.1p6, so that 
> people don't make the mistake of thinking that scopes that begin at 
> different locations are different scopes.
>
> If it weren't for that rule, no two identifiers would ever have the same 
> scope, because every identifier has a scope that begins in a different 
> location.

Except for label names.

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#112055

Steve Keller <keller@no.invalid> writes:
> While reading again in the standard about declarations and (tentative)
> definitions, and linkage, I also read about scope of identifiers and
> was confused:
>
> The standard says in 6.2.1p6 that "two identifiers have the same
> scope if and only if their scopes terminate at the same point."

Yes, and the phrase "same scope" is in italics, which means this is the
definition of the term.  Two identifiers can have the *same scope*
even if their scopes begin in different places.

It might have been less confusing if the standard had used a different
phrase, perhaps "matching scope".

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#112071

On 06/12/2017 12:38 PM, Keith Thompson wrote:
> Steve Keller <keller@no.invalid> writes:
>> While reading again in the standard about declarations and (tentative)
>> definitions, and linkage, I also read about scope of identifiers and
>> was confused:
>>
>> The standard says in 6.2.1p6 that "two identifiers have the same
>> scope if and only if their scopes terminate at the same point."
>
> Yes, and the phrase "same scope" is in italics, which means this is the
> definition of the term.  Two identifiers can have the *same scope*
> even if their scopes begin in different places.
>
> It might have been less confusing if the standard had used a different
> phrase, perhaps "matching scope".

I think the fundamental problem is at a slightly higher level. They had 
two concepts of scope, and tried to use the same name for both concepts. 
I think it would have been easier to describe things clearly if they had 
used two different terms for the two concepts. I'll use "visibility 
range" for one of the two, and "scope" for the other. Everything below 
is my suggestion how the standard could be re-written for clarity on 
this issue (it certainly does NOT describe what the standard currently 
says). My intent is to leave the actual meaning of the standard's words 
unchanged: if my suggestion fails to do that, it is my re-wording that 
is at fault.

Suggested conceptual reorganization:

An identifier's visibility range is the place where that identifier is 
visible (the definition currently provided for "scope"). An identifier's 
visibility range starts at the same exact place where the current 
standard says that it's scope starts.

A scope is a region of a program that visibility ranges could be a 
sub-set of (that's not a definition, just a shared characteristic). A 
given scope is completely independent of any identifier, and can be 
talked about even if no identifiers have been declared inside of it. 
File scope starts at the beginning of a translation unit, and continues 
to the end of it. Function scope remains unchanged from the standard's 
current definition. Block scope starts at the beginning of a block (or 
at the '(' that precedes the argument list for the outermost block of a 
function), and continues to the end of that block. Function prototype 
scope starts after the '(' that precedes the parameter list, and ends at 
the end of the function declaration.

An identifier's visibilty range ends at the end of the innermost scope 
that encloses the identifier's declaration.

Everything the standard currently says about "same scope" still applies, 
but providing a special definition of "same scope" is no longer needed: 
two scopes are the same if and only if they start an end at the same place.

I have not bothered doing a comprehensive search of the places where 
"scope" is used, so I'm not sure which cases should be changed to refer 
to "visibilty range", and which ones require a more complicated 
re-write, but I think the last three paragraphs above cover the 
trickiest issues. I hope the idea is clear from that explanation; if 
not, I can expand on it in response to sufficiently specific questions.

[toc] | [prev] | [next] | [standalone]

#112075

"James R. Kuyper" <jameskuyper@verizon.net> writes:
> On 06/12/2017 12:38 PM, Keith Thompson wrote:
>> Steve Keller <keller@no.invalid> writes:
>>> While reading again in the standard about declarations and (tentative)
>>> definitions, and linkage, I also read about scope of identifiers and
>>> was confused:
>>>
>>> The standard says in 6.2.1p6 that "two identifiers have the same
>>> scope if and only if their scopes terminate at the same point."
>>
>> Yes, and the phrase "same scope" is in italics, which means this is the
>> definition of the term.  Two identifiers can have the *same scope*
>> even if their scopes begin in different places.
>>
>> It might have been less confusing if the standard had used a different
>> phrase, perhaps "matching scope".
>
> I think the fundamental problem is at a slightly higher level. They had 
> two concepts of scope, and tried to use the same name for both concepts. 
> I think it would have been easier to describe things clearly if they had 
> used two different terms for the two concepts. I'll use "visibility 
> range" for one of the two, and "scope" for the other. Everything below 
> is my suggestion how the standard could be re-written for clarity on 
> this issue (it certainly does NOT describe what the standard currently 
> says). My intent is to leave the actual meaning of the standard's words 
> unchanged: if my suggestion fails to do that, it is my re-wording that 
> is at fault.
>
> Suggested conceptual reorganization:

Summary: For a declaration in a block, an identifiers "visibility range"
is the same as what the standard currently calls its "scope", and
extends from the declaration to the end of the block.  Its "scope" (new
meaning) extends from the beginning of the block to the end of the
block.  (Glossing over, for now, what these terms mean for scopes other
than block scope.)

I haven't checked, but I can't think of anything in the standard that
refers to your new wider "scope" other than the definition of the term
"same scope".

[vicious snip]

> Everything the standard currently says about "same scope" still applies, 
> but providing a special definition of "same scope" is no longer needed: 
> two scopes are the same if and only if they start an end at the same place.

A good goal, but I'm still not convinced that inventing a new term,
rather than using something like "matching scope" rather than "same
scope", is necessary.

> I have not bothered doing a comprehensive search of the places where 
> "scope" is used, so I'm not sure which cases should be changed to refer 
> to "visibilty range", and which ones require a more complicated 
> re-write, but I think the last three paragraphs above cover the 
> trickiest issues. I hope the idea is clear from that explanation; if 
> not, I can expand on it in response to sufficiently specific questions.


-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#112079

On 06/12/2017 03:39 PM, Keith Thompson wrote:
> "James R. Kuyper" <jameskuyper@verizon.net> writes:
...
>> I think the fundamental problem is at a slightly higher level. They had
>> two concepts of scope, and tried to use the same name for both concepts.
>> I think it would have been easier to describe things clearly if they had
>> used two different terms for the two concepts. I'll use "visibility
>> range" for one of the two, and "scope" for the other. Everything below
>> is my suggestion how the standard could be re-written for clarity on
>> this issue (it certainly does NOT describe what the standard currently
>> says). My intent is to leave the actual meaning of the standard's words
>> unchanged: if my suggestion fails to do that, it is my re-wording that
>> is at fault.
>>
>> Suggested conceptual reorganization:
>
> Summary: For a declaration in a block, an identifiers "visibility range"
> is the same as what the standard currently calls its "scope", and
> extends from the declaration to the end of the block.  Its "scope" (new
> meaning) extends from the beginning of the block to the end of the
> block.  (Glossing over, for now, what these terms mean for scopes other
> than block scope.)
>
> I haven't checked, but I can't think of anything in the standard that
> refers to your new wider "scope" other than the definition of the term
> "same scope".

If you're right (and that seems plausible) I'd take that as a 
justification for retaining "scope" for the first meaning, rather than 
the second one. Reserve the new, more complicated term for the second 
meaning.

> A good goal, but I'm still not convinced that inventing a new term,
> rather than using something like "matching scope" rather than "same
> scope", is necessary.

The term "matching scope" does not admit to a unique obvious meaning 
that fits, so what it means for two scopes to match would have to be 
defined. With an appropriate definition of some alternative term 
("extended scope"?), the meaning of "same extended scope" should be 
sufficiently clear that it doesn't need to be explicitly defined.

[toc] | [prev] | [next] | [standalone]

#112081

"James R. Kuyper" <jameskuyper@verizon.net> writes:
> On 06/12/2017 03:39 PM, Keith Thompson wrote:
>> "James R. Kuyper" <jameskuyper@verizon.net> writes:
> ...
>>> I think the fundamental problem is at a slightly higher level. They had
>>> two concepts of scope, and tried to use the same name for both concepts.
>>> I think it would have been easier to describe things clearly if they had
>>> used two different terms for the two concepts. I'll use "visibility
>>> range" for one of the two, and "scope" for the other. Everything below
>>> is my suggestion how the standard could be re-written for clarity on
>>> this issue (it certainly does NOT describe what the standard currently
>>> says). My intent is to leave the actual meaning of the standard's words
>>> unchanged: if my suggestion fails to do that, it is my re-wording that
>>> is at fault.
>>>
>>> Suggested conceptual reorganization:
>>
>> Summary: For a declaration in a block, an identifiers "visibility range"
>> is the same as what the standard currently calls its "scope", and
>> extends from the declaration to the end of the block.  Its "scope" (new
>> meaning) extends from the beginning of the block to the end of the
>> block.  (Glossing over, for now, what these terms mean for scopes other
>> than block scope.)
>>
>> I haven't checked, but I can't think of anything in the standard that
>> refers to your new wider "scope" other than the definition of the term
>> "same scope".
>
> If you're right (and that seems plausible) I'd take that as a 
> justification for retaining "scope" for the first meaning, rather than 
> the second one. Reserve the new, more complicated term for the second 
> meaning.
>
>> A good goal, but I'm still not convinced that inventing a new term,
>> rather than using something like "matching scope" rather than "same
>> scope", is necessary.
>
> The term "matching scope" does not admit to a unique obvious meaning 
> that fits, so what it means for two scopes to match would have to be 
> defined. With an appropriate definition of some alternative term 
> ("extended scope"?), the meaning of "same extended scope" should be 
> sufficiently clear that it doesn't need to be explicitly defined.

What you suggest calling an "extended scope" isn't really a scope (a
region of program text within which a given identifier is visible).  I'd
rather not introduce a term such that an "<adjective> <noun>" is not an
example of a "<noun>".

What I proposed was to replace the current definition of "same scope"
(which is problematic because two non-identical scopes can be the "same
scope") by something like "matching scope".  (I'm open to a better
adjective than "matching".)  I think that solves the (minor) problem of
"same scope" being confusing, it doesn't add to the number of defined
terms, and it's a fairly minimal change.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#112119

On Monday, June 12, 2017 at 1:19:09 PM UTC-7, Keith Thompson wrote:
> "James R. Kuyper" <jameskuyper@verizon.net> writes:
> > On 06/12/2017 03:39 PM, Keith Thompson wrote:
> >> "James R. Kuyper" <jameskuyper@verizon.net> writes:
> > ...
> >>> I think the fundamental problem is at a slightly higher level. They had
> >>> two concepts of scope, and tried to use the same name for both concepts.
> >>> I think it would have been easier to describe things clearly if they had
> >>> used two different terms for the two concepts. I'll use "visibility
> >>> range" for one of the two, and "scope" for the other. Everything below
> >>> is my suggestion how the standard could be re-written for clarity on
> >>> this issue (it certainly does NOT describe what the standard currently
> >>> says). My intent is to leave the actual meaning of the standard's words
> >>> unchanged: if my suggestion fails to do that, it is my re-wording that
> >>> is at fault.
> >>>
> >>> Suggested conceptual reorganization:
> >>
> >> Summary: For a declaration in a block, an identifiers "visibility range"
> >> is the same as what the standard currently calls its "scope", and
> >> extends from the declaration to the end of the block.  Its "scope" (new
> >> meaning) extends from the beginning of the block to the end of the
> >> block.  (Glossing over, for now, what these terms mean for scopes other
> >> than block scope.)
> >>
> >> I haven't checked, but I can't think of anything in the standard that
> >> refers to your new wider "scope" other than the definition of the term
> >> "same scope".
> >
> > If you're right (and that seems plausible) I'd take that as a 
> > justification for retaining "scope" for the first meaning, rather than 
> > the second one. Reserve the new, more complicated term for the second 
> > meaning.
> >
> >> A good goal, but I'm still not convinced that inventing a new term,
> >> rather than using something like "matching scope" rather than "same
> >> scope", is necessary.
> >
> > The term "matching scope" does not admit to a unique obvious meaning 
> > that fits, so what it means for two scopes to match would have to be 
> > defined. With an appropriate definition of some alternative term 
> > ("extended scope"?), the meaning of "same extended scope" should be 
> > sufficiently clear that it doesn't need to be explicitly defined.
> 
> What you suggest calling an "extended scope" isn't really a scope (a
> region of program text within which a given identifier is visible).  I'd
> rather not introduce a term such that an "<adjective> <noun>" is not an
> example of a "<noun>".
> 
> What I proposed was to replace the current definition of "same scope"
> (which is problematic because two non-identical scopes can be the "same
> scope") by something like "matching scope".  (I'm open to a better
> adjective than "matching".)  I think that solves the (minor) problem of
> "same scope" being confusing, it doesn't add to the number of defined
> terms, and it's a fairly minimal change.

If one looks at the case of block scope and the old C approach
one observes that all the declarations come before the statements.
If one thinks of "starting" a scope extends through all the
declarations then a single concept of "scope" holds.

This observation doesn't help the present day situation but it does
help explain how the situation cam about.

PS: If one drives this line of thought even further back it looks
as though, at some pre-C point (I am not familiar with B), each
function block started with a list of all the variables involved
including the arguments. I am familiar with such a way of doing
things in Inform 6.

[toc] | [prev] | [next] | [standalone]

#112123

On Tuesday, June 13, 2017 at 2:01:57 PM UTC-4, David Kleinecke wrote:
> On Monday, June 12, 2017 at 1:19:09 PM UTC-7, Keith Thompson wrote:
...
> > What you suggest calling an "extended scope" isn't really a scope (a
> > region of program text within which a given identifier is visible).  I'd
> > rather not introduce a term such that an "<adjective> <noun>" is not an
> > example of a "<noun>".
> > 
> > What I proposed was to replace the current definition of "same scope"
> > (which is problematic because two non-identical scopes can be the "same
> > scope") by something like "matching scope".  (I'm open to a better
> > adjective than "matching".)  I think that solves the (minor) problem of
> > "same scope" being confusing, it doesn't add to the number of defined
> > terms, and it's a fairly minimal change.
> 
> If one looks at the case of block scope and the old C approach
> one observes that all the declarations come before the statements.
> If one thinks of "starting" a scope extends through all the
> declarations then a single concept of "scope" holds.

Even though all of the declarations had to be before any of the statements,
it's expressions that matter, not statements. Because an expression can be used
to initialize an object, you can have an expression that occurs after some
identifiers have been declared, but before other identifiers in the same block
have been declared. Because the start of the scope coincides with the end of
the declarator, such initializers could only refer to identifiers previously
declared.
Changing the definition of the scope in that fashion would have allowed
initializers to refer to identifiers declared later. Since the committee did
not intend that to be permitted, that would have required a re-write of that
rule.

[toc] | [prev] | [next] | [standalone]

#112127

David Kleinecke <dkleinecke@gmail.com> writes:
> On Monday, June 12, 2017 at 1:19:09 PM UTC-7, Keith Thompson wrote:
[...]
>> What I proposed was to replace the current definition of "same scope"
>> (which is problematic because two non-identical scopes can be the "same
>> scope") by something like "matching scope".  (I'm open to a better
>> adjective than "matching".)  I think that solves the (minor) problem of
>> "same scope" being confusing, it doesn't add to the number of defined
>> terms, and it's a fairly minimal change.
>
> If one looks at the case of block scope and the old C approach
> one observes that all the declarations come before the statements.
> If one thinks of "starting" a scope extends through all the
> declarations then a single concept of "scope" holds.
>
> This observation doesn't help the present day situation but it does
> help explain how the situation cam about.

Given:

    {
        int a = 10;
        int b = a;
        int c = d; /* illegal */
        int d = 20;
        /* statements ... */
    }

the initialization of c is invalid because the scope of d doesn't start
until the line on which it's defined.

The lifetimes of all 4 objects begin at the same time, when
execution reaches the opening "{", but their scopes begin at 4
different locations.  All 4 scopes are the "same scope" as the
standard defines that phrase.  (Scope is a compile-time concept;
lifetime is a run-time concept.)

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#112159

On Tuesday, June 13, 2017 at 12:16:26 PM UTC-7, Keith Thompson wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
> > On Monday, June 12, 2017 at 1:19:09 PM UTC-7, Keith Thompson wrote:
> [...]
> >> What I proposed was to replace the current definition of "same scope"
> >> (which is problematic because two non-identical scopes can be the "same
> >> scope") by something like "matching scope".  (I'm open to a better
> >> adjective than "matching".)  I think that solves the (minor) problem of
> >> "same scope" being confusing, it doesn't add to the number of defined
> >> terms, and it's a fairly minimal change.
> >
> > If one looks at the case of block scope and the old C approach
> > one observes that all the declarations come before the statements.
> > If one thinks of "starting" a scope extends through all the
> > declarations then a single concept of "scope" holds.
> >
> > This observation doesn't help the present day situation but it does
> > help explain how the situation cam about.
> 
> Given:
> 
>     {
>         int a = 10;
>         int b = a;
>         int c = d; /* illegal */
>         int d = 20;
>         /* statements ... */
>     }
> 
> the initialization of c is invalid because the scope of d doesn't start
> until the line on which it's defined.
> 
> The lifetimes of all 4 objects begin at the same time, when
> execution reaches the opening "{", but their scopes begin at 4
> different locations.  All 4 scopes are the "same scope" as the
> standard defines that phrase.  (Scope is a compile-time concept;
> lifetime is a run-time concept.)
> 
> [...]
 
OK if you want to get pedantic. In the sense of the statements -
all the declarations happen first. They generally are such that
they can be freely shuffled around. C has taken advantage of the
fact that they have to be declared in some order to introduce
more flexibility. It can be argued that initialization is a bad
idea and should be avoided and if there are no initializations 
the declarations can be made in any order.

In other words in a primitive pre-C there was no initialization
and the declarations could be thought of as simultaneous and all
the scopes as the same. This simplicity is lost when initialization
was introduced.  

[toc] | [prev] | [next] | [standalone]

#112169

On 06/14/17 04:02 PM, David Kleinecke wrote:
> On Tuesday, June 13, 2017 at 12:16:26 PM UTC-7, Keith Thompson wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
>>> On Monday, June 12, 2017 at 1:19:09 PM UTC-7, Keith Thompson wrote:
>> [...]
>>>> What I proposed was to replace the current definition of "same scope"
>>>> (which is problematic because two non-identical scopes can be the "same
>>>> scope") by something like "matching scope".  (I'm open to a better
>>>> adjective than "matching".)  I think that solves the (minor) problem of
>>>> "same scope" being confusing, it doesn't add to the number of defined
>>>> terms, and it's a fairly minimal change.
>>>
>>> If one looks at the case of block scope and the old C approach
>>> one observes that all the declarations come before the statements.
>>> If one thinks of "starting" a scope extends through all the
>>> declarations then a single concept of "scope" holds.
>>>
>>> This observation doesn't help the present day situation but it does
>>> help explain how the situation cam about.
>>
>> Given:
>>
>>      {
>>          int a = 10;
>>          int b = a;
>>          int c = d; /* illegal */
>>          int d = 20;
>>          /* statements ... */
>>      }
>>
>> the initialization of c is invalid because the scope of d doesn't start
>> until the line on which it's defined.
>>
>> The lifetimes of all 4 objects begin at the same time, when
>> execution reaches the opening "{", but their scopes begin at 4
>> different locations.  All 4 scopes are the "same scope" as the
>> standard defines that phrase.  (Scope is a compile-time concept;
>> lifetime is a run-time concept.)
>>
>> [...]
>
> OK if you want to get pedantic.

This is Usenet...

> In the sense of the statements -
> all the declarations happen first. They generally are such that
> they can be freely shuffled around. C has taken advantage of the
> fact that they have to be declared in some order to introduce
> more flexibility. It can be argued that initialization is a bad
> idea and should be avoided and if there are no initializations
> the declarations can be made in any order.

I don't see why, why should the order be important?

-- 
Ian

[toc] | [prev] | [next] | [standalone]

#112186

On Tuesday, June 13, 2017 at 11:02:59 PM UTC-5, David Kleinecke wrote:
> In other words in a primitive pre-C there was no initialization
> and the declarations could be thought of as simultaneous and all
> the scopes as the same. This simplicity is lost when initialization
> was introduced.

Under C89, a single-pass implementation given:

   int x = expressionYieldingLotsOfCode;
   int y;

could generate code:

   bump stack pointer to leave space for x
   evaluate expresstionYieldingLotsOfCode
   bump stack pointer to leave space for y

The compiler wouldn't need to know about y, or much space it would take,
when generating code for the big expression.  Under C99, however, a
compiler has to handle:

  someLabel:
   arbitraryStatement;
   int x = expressionYieldingLotsOfCode;
   int y;

If jumping before a declaration would end a variable's lifetime, an
implementation could simply precede the jump with code that would reset
the stack pointer to the value it had the first time it ran the
arbitrary statement.  Under C99 rules, however, space would need to
remain reserved for y the second time the code runs.

[toc] | [prev] | [next] | [standalone]

#112196

supercat@casperkitty.com writes:
> On Tuesday, June 13, 2017 at 11:02:59 PM UTC-5, David Kleinecke wrote:
>> In other words in a primitive pre-C there was no initialization
>> and the declarations could be thought of as simultaneous and all
>> the scopes as the same. This simplicity is lost when initialization
>> was introduced.
>
> Under C89, a single-pass implementation given:
>
>    int x = expressionYieldingLotsOfCode;
>    int y;
>
> could generate code:
>
>    bump stack pointer to leave space for x
>    evaluate expresstionYieldingLotsOfCode
>    bump stack pointer to leave space for y
>
> The compiler wouldn't need to know about y, or much space it would take,
> when generating code for the big expression.  Under C99, however, a
> compiler has to handle:
>
>   someLabel:
>    arbitraryStatement;
>    int x = expressionYieldingLotsOfCode;
>    int y;
>
> If jumping before a declaration would end a variable's lifetime, an
> implementation could simply precede the jump with code that would reset
> the stack pointer to the value it had the first time it ran the
> arbitrary statement.  Under C99 rules, however, space would need to
> remain reserved for y the second time the code runs.

Under C90, as under C99, the lifetime of an object with automatic
storage duration begins on entry to the enclosing block.
A C90 compiler could defer allocation until control reaches the
declaration, but that's an optimization, not part of the visible
semantics.  A C99 compiler can perform exactly the same optimization
if there are no labels preceding the declaration.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#112205

On Wednesday, June 14, 2017 at 11:19:22 AM UTC-5, Keith Thompson wrote:
> Under C90, as under C99, the lifetime of an object with automatic
> storage duration begins on entry to the enclosing block.
> A C90 compiler could defer allocation until control reaches the
> declaration, but that's an optimization, not part of the visible
> semantics.  A C99 compiler can perform exactly the same optimization
> if there are no labels preceding the declaration.

The difficulty is that a conforming C99 implementation is required to
be capable of handling the case where a label precedes a declaration,
which in turn requires that it generate code to allocate space for
variables before it knows how much space they are going to require.
If a compiler's target can accommodate forward code labels but not
forward data labels, that could make things awkward.  I find it curious
that given something like:

   void weird(unsigned char **p, int x)
   {
     ONE:
       test1();
       if (x & 2) goto TWO;
       unsigned char variable;
     TWO:
       *p = &variable;
       test2();
       x++;
       if (x & 8) goto ONE;
   }

the Standard would specify that "variable" is set to Indeterminate Value
if/when execution reaches its declaration, rather than when code enters
the block containing it.  It would be possible for outside code to access
that variable's value without execution ever reaching its declaration,
and without it ever having been set to Indeterminate Value.  I don't think
the authors of the Standard really thought through the possibility of code
accessing a variable without reaching its declaration, or of code reaching
the declaration of a variable during its lifetime.

[toc] | [prev] | [next] | [standalone]

#112195

David Kleinecke <dkleinecke@gmail.com> writes:
> On Tuesday, June 13, 2017 at 12:16:26 PM UTC-7, Keith Thompson wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
[...]
>> > If one looks at the case of block scope and the old C approach
>> > one observes that all the declarations come before the statements.
>> > If one thinks of "starting" a scope extends through all the
>> > declarations then a single concept of "scope" holds.
>> >
>> > This observation doesn't help the present day situation but it does
>> > help explain how the situation cam about.
>> 
>> Given:
>> 
>>     {
>>         int a = 10;
>>         int b = a;
>>         int c = d; /* illegal */
>>         int d = 20;
>>         /* statements ... */
>>     }
>> 
>> the initialization of c is invalid because the scope of d doesn't start
>> until the line on which it's defined.
>> 
>> The lifetimes of all 4 objects begin at the same time, when
>> execution reaches the opening "{", but their scopes begin at 4
>> different locations.  All 4 scopes are the "same scope" as the
>> standard defines that phrase.  (Scope is a compile-time concept;
>> lifetime is a run-time concept.)
>> 
>> [...]
>  
> OK if you want to get pedantic.

What's pedantic about it?  You suggested

    If one thinks of "starting" a scope extends through all the
    declarations then a single concept of "scope" holds.

i.e., that the scope begins at the top of the block.  That's simply
incorrect.

>                                 In the sense of the statements -
> all the declarations happen first. They generally are such that
> they can be freely shuffled around.

As I demonstrated, they clearly can't if some declarations depend on
other declarations.

>                                     C has taken advantage of the
> fact that they have to be declared in some order to introduce
> more flexibility. It can be argued that initialization is a bad
> idea and should be avoided and if there are no initializations 
> the declarations can be made in any order.

Fortunately, I've never heard anyone argue that "initialization is
a bad idea and should be avoided".

> In other words in a primitive pre-C there was no initialization
> and the declarations could be thought of as simultaneous and all
> the scopes as the same. This simplicity is lost when initialization
> was introduced.  

I don't believe we were talking about "primitive pre-C".

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#112067

On Mon, 12 Jun 2017 18:08:42 +0200, Steve Keller <keller@no.invalid>
wrote:

>While reading again in the standard about declarations and (tentative)
>definitions, and linkage, I also read about scope of identifiers and
>was confused:
>
>The standard says in 6.2.1p6 that "two identifiers have the same
>scope if and only if their scopes terminate at the same point."
>
>That section also talks about the beginning of a scope in 6.2.1p7
>and says that except for structure, union, and enumeration tags "any
>other identifier has scope that begins just after the completion of
>its declarator."
>
>But what does that mean in case of
>
>$ nl -ba foo.c
>     1  int a;
>     2  int *p = &a;
>     3  
>     4  int foo() {
>     5      int foo = 0;
>     6      int bar = foo + 1;
>     7  }
>
>Paragraph 6.2.1p6 says that 'a' and 'p' have the same scope although
>paragraph 6.2.1p7 says that the scope of 'a' begins at the end of line 1
>while the scope of 'p' begins in line 2 right before the '='.  IMO,
>that looks contradicting, unless you also define that two scopes can
>be the same although they begin at different points.  Analoguous for
>foo and bar.
>
>Can someone explan this to me?


Possibly that could have been described a bit more clearly.

Think of it this way: an object is defined in a particular scope, but
doesn't actually exist until its definition.  Thus things before the
object's definition cannot reference the object, but things after it
can.  That's also why you can't have a duplicate name within a single
scope.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web