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

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

C scope and struct definitions

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

Contents

  C scope and struct definitions Kenneth Brody <kenbrody@spamcop.net> - 2012-06-22 13:30 -0400
    Re: C scope and struct definitions Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-22 14:02 -0400
      Re: C scope and struct definitions pacman@kosh.dhis.org (Alan Curry) - 2012-06-22 22:40 +0000
        Re: C scope and struct definitions Ben Pfaff <blp@cs.stanford.edu> - 2012-06-22 15:47 -0700
        Re: C scope and struct definitions Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-22 20:32 -0400
          Re: C scope and struct definitions pacman@kosh.dhis.org (Alan Curry) - 2012-06-23 22:06 +0000
            Re: C scope and struct definitions Keith Thompson <kst-u@mib.org> - 2012-06-23 16:18 -0700
              Re: C scope and struct definitions James Kuyper <jameskuyper@verizon.net> - 2012-06-25 10:19 -0400
                Re: C scope and struct definitions Keith Thompson <kst-u@mib.org> - 2012-06-25 11:51 -0700
            Re: C scope and struct definitions Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-23 19:54 -0400
              Re: C scope and struct definitions pacman@kosh.dhis.org (Alan Curry) - 2012-06-24 00:56 +0000
                Re: C scope and struct definitions Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-23 21:48 -0400
                  Re: C scope and struct definitions pacman@kosh.dhis.org (Alan Curry) - 2012-06-24 06:03 +0000
                    Re: C scope and struct definitions nick_keighley_nospam@hotmail.com - 2012-06-25 00:05 -0700
                Re: C scope and struct definitions Keith Thompson <kst-u@mib.org> - 2012-06-23 19:25 -0700
                  Re: C scope and struct definitions pacman@kosh.dhis.org (Alan Curry) - 2012-06-24 05:40 +0000
                    Re: C scope and struct definitions Jens Gustedt <jens.gustedt@loria.fr> - 2012-06-24 10:47 +0200
                    Re: C scope and struct definitions Keith Thompson <kst-u@mib.org> - 2012-06-24 11:00 -0700
                      Re: C scope and struct definitions pacman@kosh.dhis.org (Alan Curry) - 2012-06-25 03:53 +0000
                        Re: C scope and struct definitions Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-25 01:14 -0400
                        Re: C scope and struct definitions Keith Thompson <kst-u@mib.org> - 2012-06-24 22:38 -0700
                    Re: C scope and struct definitions Kenneth Brody <kenbrody@spamcop.net> - 2012-06-25 11:03 -0400
                      Re: C scope and struct definitions pacman@kosh.dhis.org (Alan Curry) - 2012-06-26 20:08 +0000
                        Re: C scope and struct definitions Jens Gustedt <jens.gustedt@loria.fr> - 2012-06-26 23:21 +0200
                          Re: C scope and struct definitions pacman@kosh.dhis.org (Alan Curry) - 2012-06-26 21:47 +0000
                            Re: C scope and struct definitions Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-26 18:05 -0400
                          Re: C scope and struct definitions Keith Thompson <kst-u@mib.org> - 2012-06-26 16:45 -0700
                            Re: C scope and struct definitions Jens Gustedt <jens.gustedt@loria.fr> - 2012-06-27 08:26 +0200
                              Re: C scope and struct definitions Keith Thompson <kst-u@mib.org> - 2012-06-27 00:01 -0700
                              Re: C scope and struct definitions James Kuyper <jameskuyper@verizon.net> - 2012-06-27 06:57 -0400
                                Re: C scope and struct definitions James Kuyper <jameskuyper@verizon.net> - 2012-06-27 15:00 -0400
                                  Re: C scope and struct definitions Keith Thompson <kst-u@mib.org> - 2012-06-27 14:48 -0700
                                  Re: C scope and struct definitions Tim Rentsch <txr@alumni.caltech.edu> - 2012-06-27 16:14 -0700
                                    Re: C scope and struct definitions Tim Rentsch <txr@alumni.caltech.edu> - 2012-06-29 09:36 -0700
                                  Re: C scope and struct definitions Tim Rentsch <txr@alumni.caltech.edu> - 2012-06-27 16:27 -0700
                                Re: C scope and struct definitions Keith Thompson <kst-u@mib.org> - 2012-06-27 12:03 -0700
                                Re: C scope and struct definitions Keith Thompson <kst-u@mib.org> - 2012-06-27 12:11 -0700
                              Re: C scope and struct definitions Tim Rentsch <txr@alumni.caltech.edu> - 2012-06-27 15:53 -0700
                        Re: C scope and struct definitions Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-26 17:59 -0400
                          Re: C scope and struct definitions pacman@kosh.dhis.org (Alan Curry) - 2012-06-26 22:18 +0000
                            Re: C scope and struct definitions Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-26 18:33 -0400
                            Re: C scope and struct definitions Keith Thompson <kst-u@mib.org> - 2012-06-26 17:22 -0700
                              Re: C scope and struct definitions Keith Thompson <kst-u@mib.org> - 2012-06-27 00:03 -0700
                            Re: C scope and struct definitions Kenneth Brody <kenbrody@spamcop.net> - 2012-06-27 14:13 -0400
                              Re: C scope and struct definitions Keith Thompson <kst-u@mib.org> - 2012-06-27 12:15 -0700
                                Re: C scope and struct definitions Tim Rentsch <txr@alumni.caltech.edu> - 2012-06-29 09:43 -0700
                                  Re: C scope and struct definitions Keith Thompson <kst-u@mib.org> - 2012-06-29 11:59 -0700
                                    Re: C scope and struct definitions Tim Rentsch <txr@alumni.caltech.edu> - 2012-07-01 18:32 -0700
                              Re: C scope and struct definitions pacman@kosh.dhis.org (Alan Curry) - 2012-06-27 20:59 +0000
                                Re: C scope and struct definitions Kenneth Brody <kenbrody@spamcop.net> - 2012-06-28 16:42 -0400
              Re: C scope and struct definitions James Kuyper <jameskuyper@verizon.net> - 2012-06-23 20:57 -0400
                Re: C scope and struct definitions Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-23 22:11 -0400
                  Re: C scope and struct definitions James Kuyper <jameskuyper@verizon.net> - 2012-06-23 22:51 -0400
                    Re: C scope and struct definitions Nick Bowler <nbowler@draconx.ca> - 2012-06-25 17:31 +0000
                      Re: C scope and struct definitions James Kuyper <jameskuyper@verizon.net> - 2012-06-25 14:46 -0400
                        Re: C scope and struct definitions Tim Rentsch <txr@alumni.caltech.edu> - 2012-06-25 14:43 -0700
                        Re: C scope and struct definitions Jens Gustedt <jens.gustedt@loria.fr> - 2012-06-26 13:44 +0200
                  Re: C scope and struct definitions Keith Thompson <kst-u@mib.org> - 2012-06-23 20:07 -0700
                Re: C scope and struct definitions Jens Gustedt <jens.gustedt@loria.fr> - 2012-06-24 10:56 +0200
                  Re: C scope and struct definitions James Kuyper <jameskuyper@verizon.net> - 2012-06-24 08:29 -0400
                Re: C scope and struct definitions Tim Rentsch <txr@alumni.caltech.edu> - 2012-06-24 10:26 -0700
            Re: C scope and struct definitions Kenneth Brody <kenbrody@spamcop.net> - 2012-06-25 10:50 -0400
        Re: C scope and struct definitions Tim Rentsch <txr@alumni.caltech.edu> - 2012-06-24 09:23 -0700
          Re: C scope and struct definitions Kenneth Brody <kenbrody@spamcop.net> - 2012-06-25 11:17 -0400
            Re: C scope and struct definitions Tim Rentsch <txr@alumni.caltech.edu> - 2012-06-25 14:22 -0700
    Re: C scope and struct definitions Kenneth Brody <kenbrody@spamcop.net> - 2012-06-25 11:11 -0400

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#22836

On 6/26/2012 6:18 PM, Alan Curry wrote:
> In article <jsdbb6$t43$1@dont-email.me>,
> Eric Sosman  <esosman@ieee-dot-org.invalid> wrote:
>> On 6/26/2012 4:08 PM, Alan Curry wrote:
>>>
>>> Scope is the boundary of a variable's existence at compile time.
>>
>>      Ah.  This is obviously some strange usage of the word "scope"
>> that I hadn't previously been aware of.  More to the point, it's a
>
> It's an explanation of the concept, in my own words, deliberately chosen to
> not look like standardese. I did that because I believe if you can't explain
> something in your own words, you don't really understand it.

     If you want to discuss a technical topic, you'd better be
prepared to use and understand technical language in accordance
with accepted definitions.  It's simply a non-starter to stroll
around with your own private definition of "kilogram" as "one
thousand telegrams."  When you do so you are not communicating;
you are obfuscating.

>>      Well, no.  Whenever an auto variable's identifier is in scope,
>> that identifier exists, yes.  But the opposite does not hold: Even

     (Should have been "that *variable* exists;" sorry for the typo.)

>> while the variable exists, its identifier can be out of scope.  (I
>> can think of three ways for this to happen; there may be others.)
>
> That's a fun puzzle. Shadowing of course, which is a "don't do that".
> Preprocessor effects ruled out, I assume. Maybe a variant of shadowing in
> which typedef is used in an inner block.

     Re-using an identifier in a contained block is one way, yes.
Here's an example of another:

	int count_bits(unsigned int value) {
	    int bits;
	    for (bits = 0; value != 0; value &= value - 1)
	        ++bits;
	    return bits;
	}

	void driver(void) {
	    for (unsigned int x = 0; x < 42; ++x)
	        printf("%d has %d 1-bits\n", x, count_bits(x));
	}

Note that count_bits() runs forty-two times during the lifetime
of the variable denoted by `x' in driver(), yet `x' is out of
scope in all forty-two executions.

     And here's my third example:

	void precision_is_important(void) {
	    // Lifetime of the variable named `x' starts HERE,
	    // but the identifier is not in scope.
	    printf("Hello, world!\n");
	    int x = 42;  // `x' now comes into scope.
	    printf("The answer is %d\n", x);
	}  // Scope and lifetime both end HERE.

     B-u-u-t, if you're going to use your own private meanings
for terms like "scope" and "lifetime," I hope you won't mind
me using my own meanings for terms like "nonsense."

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

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

#22841

pacman@kosh.dhis.org (Alan Curry) writes:
[...]
> A variable is a name, a value, an address, or some combination of those
> possibilities, depending on when you look at it. When you're writing the code
> (as opposed to compiling and running it), the variable is the name. If you
> saw something like
>
>   void foo(int i)
>   {
>     /*something*/
>   }
>
>   int bar(void)
>   {
>     return i;
>   }
>
> Wouldn't you think it's reasonable to say that the reason bar() won't compile
> is that the variable i doesn't exist there? If you don't accept that wording,
> then you're too much of a language lawyer to ever make sense of the way real
> programmers talk.
[...]

I asked upthread what you mean by "variable"; I hadn't yet read
the above.

In my opinion, saying that a variable is "a name, a value, an
address, or some combination of those possibilities, depending on
when you look at it" makes the term far too vague to be useful,
especially without knowing *how* it depends on when you look at it.
Which is why I prefer to use well-defined terms like "object" and
"identifier".

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#22852

Keith Thompson <kst-u@mib.org> writes:
> pacman@kosh.dhis.org (Alan Curry) writes:
> [...]
>> A variable is a name, a value, an address, or some combination of those
>> possibilities, depending on when you look at it. When you're writing the code
>> (as opposed to compiling and running it), the variable is the name. If you
>> saw something like
[snip]
> I asked upthread what you mean by "variable"; I hadn't yet read
> the above.
>
> In my opinion, saying that a variable is "a name, a value, an
> address, or some combination of those possibilities, depending on
> when you look at it" makes the term far too vague to be useful,
> especially without knowing *how* it depends on when you look at it.
> Which is why I prefer to use well-defined terms like "object" and
> "identifier".

Sorry, I didn't keep track of who wrote what.  I had asked Jens Gustedt
what he meant by "variable".

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#22880

On 6/26/2012 6:18 PM, Alan Curry wrote:
> In article <jsdbb6$t43$1@dont-email.me>,
> Eric Sosman  <esosman@ieee-dot-org.invalid> wrote:
>> On 6/26/2012 4:08 PM, Alan Curry wrote:
>>>
>>> Scope is the boundary of a variable's existence at compile time.
>>
>>      Ah.  This is obviously some strange usage of the word "scope"
>> that I hadn't previously been aware of.  More to the point, it's a
>
> It's an explanation of the concept, in my own words, deliberately chosen to
> not look like standardese. I did that because I believe if you can't explain
> something in your own words, you don't really understand it.

But, you used "standardese" words to do so, thereby making it sound as if 
you were misunderstanding the concepts.  If you're going to use words that 
have a specific meaning in the context you're using them, but you choose to 
use them for something else, you are at great risk for being misunderstood.

While you might get away with calling the main box of a desktop computer the 
"CPU", you would be way off base to call it the "hard drive" (as I have seen 
done way too often).

[...]
> A variable is a name, a value, an address, or some combination of those
> possibilities, depending on when you look at it.

But, we were talking about "identifiers", of which "variables" are just a 
small subset.

> When you're writing the code
> (as opposed to compiling and running it), the variable is the name. If you
> saw something like
>
>    void foo(int i)
>    {
>      /*something*/
>    }
>
>    int bar(void)
>    {
>      return i;
>    }
>
> Wouldn't you think it's reasonable to say that the reason bar() won't compile
> is that the variable i doesn't exist there?

If you word it that way, yes.  If you were to use the more technical "not in 
scope", then yes as well.  However, if you were to use something about the 
"lifetime" of "i", then I would have to disagree.

> If you don't accept that wording,
> then you're too much of a language lawyer to ever make sense of the way real
> programmers talk.

The problem was that you were using "scope" in a way different than its 
defined meaning in the context of the C language.

>>> Lifetime is
>>> the boundary of a variable's existence at runtime. They're basically the same
>>> thing in different dimensions (temporal at runtime, spatial at compile time).
>>> And for local variables, they both default to the block enclosing the
>>> declaration. At compile time, the variable can be referenced (i.e. its name
>>> can be used) while that block is being parsed. At runtime, the variable can
>>> be referenced (i.e. its value can be loaded from memory) while that block is
>>> active.
>>
>>      Well, no.  Whenever an auto variable's identifier is in scope,
>> that identifier exists, yes.  But the opposite does not hold: Even
>> while the variable exists, its identifier can be out of scope.  (I
>> can think of three ways for this to happen; there may be others.)
>
> That's a fun puzzle. Shadowing of course, which is a "don't do that".
> Preprocessor effects ruled out, I assume. Maybe a variant of shadowing in
> which typedef is used in an inner block.

Not to mention a simple function call.

     void foo(void)
         {
         int i;
         bar();
         }
     void bar(void)
         {
         /* "i" still exists, but is out of scope. */
         }

-- 
Kenneth Brody

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

#22890

Kenneth Brody <kenbrody@spamcop.net> writes:
> On 6/26/2012 6:18 PM, Alan Curry wrote:
[...]
>> A variable is a name, a value, an address, or some combination of those
>> possibilities, depending on when you look at it.
>
> But, we were talking about "identifiers", of which "variables" are just a 
> small subset.

I've seen several people say that a variable is a kind of identifier.

I've always thought of a variable as a kind of *object*.

For example, given:

    int xyz;

I'd say that "xyz is a variable", but what I mean by that is that the
object whose name is "xyz" is a variable.  The identifier "xyz" isn't a
"variable"; it's the *name* of a variable.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#22985

Keith Thompson <kst-u@mib.org> writes:

> Kenneth Brody <kenbrody@spamcop.net> writes:
>> On 6/26/2012 6:18 PM, Alan Curry wrote:
> [...]
>>> A variable is a name, a value, an address, or some combination of those
>>> possibilities, depending on when you look at it.
>>
>> But, we were talking about "identifiers", of which "variables" are just a 
>> small subset.
>
> I've seen several people say that a variable is a kind of identifier.
>
> I've always thought of a variable as a kind of *object*.
>
> For example, given:
>
>     int xyz;
>
> I'd say that "xyz is a variable", but what I mean by that is that the
> object whose name is "xyz" is a variable.  The identifier "xyz" isn't a
> "variable"; it's the *name* of a variable.

A question for clarification -- if we have a function defined as

    int
    nabs( int n0 ){
        int n = n0;
        return  n > 0  ?  nabs( -n )  :  n;
    }

and there is a call 'nabs( 1 )', then (ignoring the parameter n0)
would you say there is one variable or two?  I would say there is
one variable, and two instances of that variable.

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

#22997

Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Kenneth Brody <kenbrody@spamcop.net> writes:
>>> On 6/26/2012 6:18 PM, Alan Curry wrote:
>> [...]
>>>> A variable is a name, a value, an address, or some combination of those
>>>> possibilities, depending on when you look at it.
>>>
>>> But, we were talking about "identifiers", of which "variables" are just a 
>>> small subset.
>>
>> I've seen several people say that a variable is a kind of identifier.
>>
>> I've always thought of a variable as a kind of *object*.
>>
>> For example, given:
>>
>>     int xyz;
>>
>> I'd say that "xyz is a variable", but what I mean by that is that the
>> object whose name is "xyz" is a variable.  The identifier "xyz" isn't a
>> "variable"; it's the *name* of a variable.
>
> A question for clarification -- if we have a function defined as
>
>     int
>     nabs( int n0 ){
>         int n = n0;
>         return  n > 0  ?  nabs( -n )  :  n;
>     }
>
> and there is a call 'nabs( 1 )', then (ignoring the parameter n0)
> would you say there is one variable or two?  I would say there is
> one variable, and two instances of that variable.

I'd probably say that there are two variables (i.e., what you call an
"instance of a variable" I call a "variable").

I have no great confidence that my usage is correct and yours is
incorrect -- which is yet another reason why (at least here in clc) I
tend to avoid using the word "variable" if there's any chance of
ambiguity.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#23064

Keith Thompson <kst-u@mib.org> writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>> Kenneth Brody <kenbrody@spamcop.net> writes:
>>>> On 6/26/2012 6:18 PM, Alan Curry wrote:
>>> [...]
>>>>> A variable is a name, a value, an address, or some combination of those
>>>>> possibilities, depending on when you look at it.
>>>>
>>>> But, we were talking about "identifiers", of which "variables" are just a 
>>>> small subset.
>>>
>>> I've seen several people say that a variable is a kind of identifier.
>>>
>>> I've always thought of a variable as a kind of *object*.
>>>
>>> For example, given:
>>>
>>>     int xyz;
>>>
>>> I'd say that "xyz is a variable", but what I mean by that is that the
>>> object whose name is "xyz" is a variable.  The identifier "xyz" isn't a
>>> "variable"; it's the *name* of a variable.
>>
>> A question for clarification -- if we have a function defined as
>>
>>     int
>>     nabs( int n0 ){
>>         int n = n0;
>>         return  n > 0  ?  nabs( -n )  :  n;
>>     }
>>
>> and there is a call 'nabs( 1 )', then (ignoring the parameter n0)
>> would you say there is one variable or two?  I would say there is
>> one variable, and two instances of that variable.
>
> I'd probably say that there are two variables (i.e., what you call an
> "instance of a variable" I call a "variable").
>
> I have no great confidence that my usage is correct and yours is
> incorrect -- which is yet another reason why (at least here in clc) I
> tend to avoid using the word "variable" if there's any chance of
> ambiguity.

I don't think either usage is right or wrong necessarily.  At some
level I don't care what terms people use, as long as what they say
is clear and the various terms are used consistently.  We might
call them "translation-time variables" and "execution-time
variables", and I think most people would understand the different
meanings intended.  As one data point, the page at Wikipedia that
describes "variables" (as used with computers), uses the term in
the sense of "execution-time variable" (ie, what you call just a
variable).  However, that very same page also talks about declaring
a variable, which is of course nonsensical under that sense of the
term -- one doesn't declare each execution-time variable that may
come into existence during a given program run;  rather one
declares a translation-time variable that serves as a kind of
template for the many execution-time variables that arise as a
result of the single declaration.

Again, I don't care so much what terms are used, but I don't think
it's too much to ask -- especially in highly technical writing like
that used in the Standard -- that a distinction be made between a
translation-time notion and the related execution-time notion.
Certainly the two notions are strongly related;  but the difference
between them is also significant, IMO profoundly so.

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

#22897

In article <IKCdnQnYo6fW0HbSnZ2dnUVZ_qidnZ2d@bestweb.net>,
Kenneth Brody  <kenbrody@spamcop.net> wrote:
>On 6/26/2012 6:18 PM, Alan Curry wrote:
>> In article <jsdbb6$t43$1@dont-email.me>,
>> Eric Sosman  <esosman@ieee-dot-org.invalid> wrote:
>>> On 6/26/2012 4:08 PM, Alan Curry wrote:
>>>>
>>>> Scope is the boundary of a variable's existence at compile time.
>>>
>>>      Ah.  This is obviously some strange usage of the word "scope"
>>> that I hadn't previously been aware of.  More to the point, it's a
>>
>> It's an explanation of the concept, in my own words, deliberately chosen to
>> not look like standardese. I did that because I believe if you can't explain
>> something in your own words, you don't really understand it.
>
>But, you used "standardese" words to do so, thereby making it sound as if 
>you were misunderstanding the concepts.  If you're going to use words that 
>have a specific meaning in the context you're using them, but you choose to 
>use them for something else, you are at great risk for being misunderstood.

Well, "scope" is a word with standardized meaning, yes. And I think the
definition I provided above is 100% consistent with that standardized
meaning. It's just shorter because it's written in plain language (plain for
progammers anyway).

>
>> When you're writing the code
>> (as opposed to compiling and running it), the variable is the name. If you
>> saw something like
>>
>>    void foo(int i)
>>    {
>>      /*something*/
>>    }
>>
>>    int bar(void)
>>    {
>>      return i;
>>    }
>>
>> Wouldn't you think it's reasonable to say that the reason bar() won't compile
>> is that the variable i doesn't exist there?
>
>If you word it that way, yes.  If you were to use the more technical "not in 
>scope", then yes as well.  However, if you were to use something about the 
>"lifetime" of "i", then I would have to disagree.

That wouldn't be a normal usage coming from me either. I don't think I've
heard it before.

>
>> If you don't accept that wording,
>> then you're too much of a language lawyer to ever make sense of the way real
>> programmers talk.
>
>The problem was that you were using "scope" in a way different than its 
>defined meaning in the context of the C language.

I don't think I was. Show me where you think my definition of scope as "the
boundary of a variable's existence at compile time" diverges from a correct
definition.

>>>
>>>      Well, no.  Whenever an auto variable's identifier is in scope,
>>> that identifier exists, yes.  But the opposite does not hold: Even
>>> while the variable exists, its identifier can be out of scope.  (I
>>> can think of three ways for this to happen; there may be others.)
>>
>> That's a fun puzzle. Shadowing of course, which is a "don't do that".
>> Preprocessor effects ruled out, I assume. Maybe a variant of shadowing in
>> which typedef is used in an inner block.
>
>Not to mention a simple function call.
>
>     void foo(void)
>         {
>         int i;
>         bar();
>         }
>     void bar(void)
>         {
>         /* "i" still exists, but is out of scope. */
>         }

I wouldn't accept that as a solution to the puzzle as stated. The variable i
doesn't exist inside bar. At runtime, they may exist simultaneously, and you
can even add a way for bar to modify i by passing a pointer to it. But that's
only runtime coexistence. The variable "i" isn't fully present inside of bar.
So... half credit.

And everything I just said can be put down in dry sentences that perfectly
describe everything using the official terminology of "lifetime" and "scope".
I know how to write those sentences, I promise. But I still say there's room
for discussion among programmers using colloquial language, and that it can
be a more powerful form of communication than standard-quoting. Fall back on
standard-quoting when there's a dispute that can't be resolved any other way.

-- 
Alan Curry

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

#22952

On 6/27/2012 4:59 PM, Alan Curry wrote:
> In article <IKCdnQnYo6fW0HbSnZ2dnUVZ_qidnZ2d@bestweb.net>,
> Kenneth Brody  <kenbrody@spamcop.net> wrote:
[..]
>>> If you don't accept that wording,
>>> then you're too much of a language lawyer to ever make sense of the way real
>>> programmers talk.
>>
>> The problem was that you were using "scope" in a way different than its
>> defined meaning in the context of the C language.
>
> I don't think I was. Show me where you think my definition of scope as "the
> boundary of a variable's existence at compile time" diverges from a correct
> definition.

At this point in the discussion, it's quite possible that it was someone 
else's comment in an earlier sub-thread which I was thinking of.  There was 
definitely a cross-over regarding the usage of "lifetime" and "scope" at 
that point.

>>>>       Well, no.  Whenever an auto variable's identifier is in scope,
>>>> that identifier exists, yes.  But the opposite does not hold: Even
>>>> while the variable exists, its identifier can be out of scope.  (I
>>>> can think of three ways for this to happen; there may be others.)
>>>
>>> That's a fun puzzle. Shadowing of course, which is a "don't do that".
>>> Preprocessor effects ruled out, I assume. Maybe a variant of shadowing in
>>> which typedef is used in an inner block.
>>
>> Not to mention a simple function call.
>>
>>      void foo(void)
>>          {
>>          int i;
>>          bar();
>>          }
>>      void bar(void)
>>          {
>>          /* "i" still exists, but is out of scope. */
>>          }
>
> I wouldn't accept that as a solution to the puzzle as stated. The variable i
> doesn't exist inside bar. At runtime, they may exist simultaneously, and you
> can even add a way for bar to modify i by passing a pointer to it. But that's
> only runtime coexistence. The variable "i" isn't fully present inside of bar.
> So... half credit.

But, it does "exist".  The fact that it can't be accessed because it's out 
of scope, and its existence has no impact on bar(), is irrelevant.

> And everything I just said can be put down in dry sentences that perfectly
> describe everything using the official terminology of "lifetime" and "scope".
> I know how to write those sentences, I promise. But I still say there's room
> for discussion among programmers using colloquial language, and that it can
> be a more powerful form of communication than standard-quoting. Fall back on
> standard-quoting when there's a dispute that can't be resolved any other way.

-- 
Kenneth Brody

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

#22593

On 06/23/2012 07:54 PM, Eric Sosman wrote:
...
>      But once you've decided to declare a function with a prototype,
> what scope should any identifiers in the prototype have?  It seems
> pretty clear you don't want them leaking outside, else
> 
> 	void foo(char *p);
> 	void bar(double *p);
> 
> ... wouldn't compile, because of the conflicting declarations of `p'.
> I suggest that would have been untenable.
> 
>      A consequence of "What happens in prototype stays in prototype"
> is that *all* in-prototype identifiers' scopes are limited to the
> prototype itself.  Yes, it leads to a useless construct -- but have
> you got a usable alternative?

Two:
C++ way: prohibit definition of types in there parameter list of a
function declaration.

Useful alternative: give types defined in a function's parameter list
the same scope as the function's declaration, rather than function
prototype scope.

...
>      I'm glad the Standard didn't take your view.  While I'll admit
> that function-specific types are not all that common, I'll maintain
> that they are extremely useful.  Most often, there's an ad-hoc
> table of some kind to assist a function in the performance of its
> work: Maybe an association of states with their capitols, or ranges
> of `x' where a rational function/Chebyshev approximation/continued
> fraction is the preferred computation method.  Whatever it is, if
> it's specific to the operation of one function I see *no* reason to
> inflict it on others.

Agreed; for things declared inside of a function, that's entirely
reasonable. But for a type that's part of a function's interface, if the
identifier for that type has a scope is limited to the function body, no
other function can call it - which is rather limiting.

>> A struct describes the procedure for interpreting bits in memory. As a
>> procedure description, it's more like a function than a variable. It doesn't
>> occupy memory itself, so it doesn't have a lifetime that can end when the
>> function call ends. Putting it inside the function gives you nothing.
> 
>      All the same statements could be made about an identifier of any
> kind whatsoever.  Should `x' leak out of one function into others?

No, only identifiers identifying types should leak out, only when they
are part of the parameter list.
-- 
James Kuyper

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

#22595

On 6/23/2012 8:57 PM, James Kuyper wrote:
> On 06/23/2012 07:54 PM, Eric Sosman wrote:
>> [...]
>>       A consequence of "What happens in prototype stays in prototype"
>> is that *all* in-prototype identifiers' scopes are limited to the
>> prototype itself.  Yes, it leads to a useless construct -- but have
>> you got a usable alternative?
>
> Two:
> C++ way: prohibit definition of types in there parameter list of a
> function declaration.

     I'm not a C++ lawyer (nor even a C++ fluent speaker (although I
have "C++ Readability," go figure)), but "no type declarations in
function declarations" seems awfully restrictive:

	int main(int argc, char **argv)  // BZZZZT!

What must one do instead?

	typedef char **charStarStar;
	int main(int argc, charStarStar argv)

?  But, as I say, I don't speak That Other Language, and maybe I've
read more into your synopsis than was actually present.

> Useful alternative: give types defined in a function's parameter list
> the same scope as the function's declaration, rather than function
> prototype scope.

     I'd worked up a nice reductio ad absurdum, and then realized that
you meant something other than what you'd said: You said "same scope
as the function's *declaration*," but you meant "same scope as the
function's *identifier*."  I dunno: Might be reasonable, might have
unwelcome consequences in corner cases, might disable some corner
cases that are legitimate now but Ought To Be Banned (Just Think Of
The Children!), ...  Needs more thought than my graying gray cells
can muster.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

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

#22597

On 06/23/2012 10:11 PM, Eric Sosman wrote:
> On 6/23/2012 8:57 PM, James Kuyper wrote:
>> On 06/23/2012 07:54 PM, Eric Sosman wrote:
>>> [...]
>>>       A consequence of "What happens in prototype stays in prototype"
>>> is that *all* in-prototype identifiers' scopes are limited to the
>>> prototype itself.  Yes, it leads to a useless construct -- but have
>>> you got a usable alternative?
>>
>> Two:
>> C++ way: prohibit definition of types in there parameter list of a
>> function declaration.
> 
>      I'm not a C++ lawyer (nor even a C++ fluent speaker (although I
> have "C++ Readability," go figure)), but "no type declarations in
> function declarations" seems awfully restrictive:
> 
> 	int main(int argc, char **argv)  // BZZZZT!

I said "type definition", not type declaration. Neither int nor char**
were defined in that declaration, they were only specified as the types
of the corresponding parameters. They aren't identifiers, they don't
have a scope associated with them. Types that have scoped identifiers
that can be defined by user code include struct, union, and enum types.

>> Useful alternative: give types defined in a function's parameter list
>> the same scope as the function's declaration, rather than function
>> prototype scope.
> 
>      I'd worked up a nice reductio ad absurdum, and then realized that
> you meant something other than what you'd said: You said "same scope
> as the function's *declaration*," but you meant "same scope as the
> function's *identifier*."  I dunno: Might be reasonable, might have
> unwelcome consequences in corner cases, might disable some corner
> cases that are legitimate now but Ought To Be Banned (Just Think Of
> The Children!), ...  Needs more thought than my graying gray cells
> can muster.

Yes, think on it. Function declarations that would be affected by this
suggestion are useless, so I don't see how it could break existing
working code. Other kinds of unwelcome consequences are certainly
possible, of course.
-- 
James Kuyper

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

#22698

On Sat, 23 Jun 2012 22:51:56 -0400, James Kuyper wrote:
>>> Useful alternative: give types defined in a function's parameter list
>>> the same scope as the function's declaration, rather than function
>>> prototype scope.
[...]
> Yes, think on it. Function declarations that would be affected by this
> suggestion are useless, so I don't see how it could break existing
> working code. Other kinds of unwelcome consequences are certainly
> possible, of course.

I'd agree that such declarations are likely "useless", by which I mean
that I'd prefer not to be caught writing a program which relied on this
aspect of the C language.  However, it's easy to construct a program
(i.e., "existing working code") that would break if you made this
change.  The following is valid in C today:

  int main(void) {
    void foo(struct baz { int x; } *);
    void bar(struct baz { int x; } *);

    foo(0);
    bar(0);
  }

With your proposed change, the second declaration would presumably
result in multiple definitions of struct bar in the same scope, and
thus become a syntax error.

(Note that for the above function calls work, foo and bar *must* be
defined in a separate translation unit for the struct compatibility
rules in C11§6.2.7p1 to apply).

That being said, breaking the above program may be a good thing.
Both of your proposals accomplish this.

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

#22699

On 06/25/2012 01:31 PM, Nick Bowler wrote:
> On Sat, 23 Jun 2012 22:51:56 -0400, James Kuyper wrote:
>>>> Useful alternative: give types defined in a function's parameter list
>>>> the same scope as the function's declaration, rather than function
>>>> prototype scope.
> [...]
>> Yes, think on it. Function declarations that would be affected by this
>> suggestion are useless, so I don't see how it could break existing
>> working code. Other kinds of unwelcome consequences are certainly
>> possible, of course.
> 
> I'd agree that such declarations are likely "useless", by which I mean
> that I'd prefer not to be caught writing a program which relied on this
> aspect of the C language. ...

I'd put it a little differently. I can't imagine anyone writing such
code except in ignorance of the subtle issues that render it "almost"
useless, and they should quickly discover its near-uselessness the first
time that they try to compile code which actually tries to use any such
function declaration.

> ... However, it's easy to construct a program
> (i.e., "existing working code") that would break if you made this
> change.  The following is valid in C today:
> 
>   int main(void) {
>     void foo(struct baz { int x; } *);
>     void bar(struct baz { int x; } *);
> 
>     foo(0);
>     bar(0);

Note that this code depends upon the fact that a null pointer constant
gets implicitly converted to the parameter's type - no explicit
conversion is needed. This is good, because C doesn't provide any way to
explicitly specify a target type compatible with the the parameter's type.

In essence, such a declaration says "don't use this function with any
arguments except null pointer constants". It would be simpler to have
the function take no argument at all.

>   }
> 
> With your proposed change, the second declaration would presumably
> result in multiple definitions of struct bar in the same scope, and
> thus become a syntax error.

If the author of such code intended for the declaration to impose the
severe restrictions on how the function could be used, that it does
impose under the current rules, it would have been simpler to declare it
as taking no arguments. If that was not intentional, the code should be
fixed. Either way, I don't see any good reason for such code to be
protected from becoming a syntax error.

> (Note that for the above function calls work, foo and bar *must* be
> defined in a separate translation unit for the struct compatibility
> rules in C11§6.2.7p1 to apply).
> 
> That being said, breaking the above program may be a good thing.

I think so.

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

#22734

James Kuyper <jameskuyper@verizon.net> writes:

> On 06/25/2012 01:31 PM, Nick Bowler wrote:
>> On Sat, 23 Jun 2012 22:51:56 -0400, James Kuyper wrote:
>>>>> Useful alternative: give types defined in a function's parameter list
>>>>> the same scope as the function's declaration, rather than function
>>>>> prototype scope.
>> [...]
>>> Yes, think on it. Function declarations that would be affected by this
>>> suggestion are useless, so I don't see how it could break existing
>>> working code. Other kinds of unwelcome consequences are certainly
>>> possible, of course.
>> 
>> I'd agree that such declarations are likely "useless", by which I mean
>> that I'd prefer not to be caught writing a program which relied on this
>> aspect of the C language. [snip response]  However, it's easy to
>> construct a program (i.e., "existing working code") that would break
>> if you made this change.  The following is valid in C today:
>> 
>>   int main(void) {
>>     void foo(struct baz { int x; } *);
>>     void bar(struct baz { int x; } *);
>> 
>>     foo(0);
>>     bar(0);
>
> Note that this code depends upon the fact that a null pointer constant
> gets implicitly converted to the parameter's type - no explicit
> conversion is needed. This is good, because C doesn't provide any way to
> explicitly specify a target type compatible with the the parameter's type.

But C does provide a way to specify (for any pointer value, not just
null pointer constants) a target type that is assignment-acceptable,
which is all that is needed.  (Nit: yes I meant object pointer, not
function pointer.)

> In essence, such a declaration says "don't use this function with any
> arguments except null pointer constants". [snip elaboration]

That is overstating the case.  See above.

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

#22785

Am 25.06.2012 20:46, schrieb James Kuyper:
> On 06/25/2012 01:31 PM, Nick Bowler wrote:
>> ... However, it's easy to construct a program
>> (i.e., "existing working code") that would break if you made this
>> change.  The following is valid in C today:
>>
>>   int main(void) {
>>     void foo(struct baz { int x; } *);
>>     void bar(struct baz { int x; } *);
>>
>>     foo(0);
>>     bar(0);
> 
> Note that this code depends upon the fact that a null pointer constant
> gets implicitly converted to the parameter's type - no explicit
> conversion is needed. This is good, because C doesn't provide any way to
> explicitly specify a target type compatible with the the parameter's type.
> 
> In essence, such a declaration says "don't use this function with any
> arguments except null pointer constants". It would be simpler to have
> the function take no argument at all.

no, you forget another important possible use case, void*. E.g
something like

foo(malloc(bigNumber));

would be a valid call as well.

>> (Note that for the above function calls work, foo and bar *must* be
>> defined in a separate translation unit for the struct compatibility
>> rules in C11§6.2.7p1 to apply).

yes, thing that I always found bizarre

Another resolution of this scope problem would be to do the same as
C11 allows for typedef's: if the type is exactly the same (this could
reuse the wording of the section for compatible type) then a
redefinition could be allowed.

>> That being said, breaking the above program may be a good thing.
> 
> I think so.

definitively

Jens

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

#22598

Eric Sosman <esosman@ieee-dot-org.invalid> writes:
> On 6/23/2012 8:57 PM, James Kuyper wrote:
[...]
>> Two:
>> C++ way: prohibit definition of types in there parameter list of a
>> function declaration.
>
>      I'm not a C++ lawyer (nor even a C++ fluent speaker (although I
> have "C++ Readability," go figure)), but "no type declarations in
> function declarations" seems awfully restrictive:
>
> 	int main(int argc, char **argv)  // BZZZZT!
>
> What must one do instead?
>
> 	typedef char **charStarStar;
> 	int main(int argc, charStarStar argv)
>
> ?  But, as I say, I don't speak That Other Language, and maybe I've
> read more into your synopsis than was actually present.

I think the restriction in C++ is that you can't define a new type name
(either a typedef name or a tag) in a prototype or as a return type.
"char**" is, in some sense, an existing type, not a new one.

I haven't found the rule in the C++ standard that states this
explicitly, but the annex that describes incompatibilities between C and
C++ mentions it.

For example, this:

    void f( struct S { int a; } arg ) {}

is valid in C, but invalid in C++.  (I'd say it's poor style in C.)

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#22604

Am 24.06.2012 02:57, schrieb James Kuyper:
> On 06/23/2012 07:54 PM, Eric Sosman wrote:
>>      A consequence of "What happens in prototype stays in prototype"
>> is that *all* in-prototype identifiers' scopes are limited to the
>> prototype itself.  Yes, it leads to a useless construct -- but have
>> you got a usable alternative?
> 
> Two:
> C++ way: prohibit definition of types in there parameter list of a
> function declaration.
> 
> Useful alternative: give types defined in a function's parameter list
> the same scope as the function's declaration, rather than function
> prototype scope.

I don't think that this alternative would buy us much and would add up
to confusion. Remember that struct can only be declared once, so the
definition of such a function then must look (syntactically) different
from the prototype since it can't redeclare the struct.

There can only be some marginal code base that uses struct definitions
in prototypes directly. They are basically useless. So the C++
treatment would be a possible addition to C.

Jens

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

#22606

On 06/24/2012 04:56 AM, Jens Gustedt wrote:
> Am 24.06.2012 02:57, schrieb James Kuyper:
>> On 06/23/2012 07:54 PM, Eric Sosman wrote:
>>>      A consequence of "What happens in prototype stays in prototype"
>>> is that *all* in-prototype identifiers' scopes are limited to the
>>> prototype itself.  Yes, it leads to a useless construct -- but have
>>> you got a usable alternative?
>>
>> Two:
>> C++ way: prohibit definition of types in there parameter list of a
>> function declaration.
>>
>> Useful alternative: give types defined in a function's parameter list
>> the same scope as the function's declaration, rather than function
>> prototype scope.
> 
> I don't think that this alternative would buy us much and would add up
> to confusion. Remember that struct can only be declared once, so the
> definition of such a function then must look (syntactically) different
> from the prototype since it can't redeclare the struct.

Yes, that is a valid point.

> There can only be some marginal code base that uses struct definitions
> in prototypes directly. They are basically useless. So the C++
> treatment would be a possible addition to C.

I've no objection to adopting the C++ approach, just pointing out that
there are workable alternatives. The current rules allow a declaration
that is useless for some rather subtle reasons, and I don't think that's
a good idea.
-- 
James Kuyper

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

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

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

csiph-web