 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Kenneth Brody
Guest
|
 Posted: Mon Jun 25, 2012 1:11 pm Post subject: Re: C scope and struct definitions |
 |
|
On 6/22/2012 1:30 PM, Kenneth Brody wrote:
| Quote: | The discussion about scope in the "What a stupid gcc" thread reminded me of
the one time (that I recall) where I was bitten by this. I don't recall the
specifics, but it had to do with a function that was passed a pointer to a
struct, when there was no struct by that name visible.
[...] |
As a quick followup (and thank you to all those who not only answered my
original question, but have gone way beyond it as well), here is a simple
"gcc" example:
==========
[/tmp]$ cat usenet.c
void foo( struct bar *pt );
void foo( struct bar *pt )
{
return;
}
[/tmp]$ gcc -Wall -c usenet.c
usenet.c:1: warning: `struct bar' declared inside parameter list
usenet.c:1: warning: its scope is only this definition or declaration,
usenet.c:1: warning: which is probably not what you want.
usenet.c:3: warning: `struct bar' declared inside parameter list
usenet.c:4: conflicting types for `foo'
usenet.c:1: previous declaration of `foo'
[/tmp]$
==========
If it weren't for the explanatory "its scope is only this definition ..."
lines, it would be very confusing to figure out why the prototype
void foo( struct bar *pt );
and the definition:
void foo( struct bar *pt )
are "conflicting types".
--
Kenneth Brody |
|
| Back to top |
|
 |
Kenneth Brody
Guest
|
| Posted: Mon Jun 25, 2012 1:17 pm Post subject: Re: C scope and struct definitions |
|
|
On 6/24/2012 12:23 PM, Tim Rentsch wrote:
[...]
| Quote: | Surely not a historical accident, because prototypes didn't exist
in C before it was standardized.
[...]
Also, the behavior in C probably was chosen to match the behavior
in C++, from whence prototypes were derived. So this is really
a C++ question rather than a C question (1/2  .
|
I don't see this as a strictly prototype-related question. It's just that
prototypes give the compiler an opportunity to warn you about it if necessary.
For example:
int foo(pt)
struct foobar *pt;
{
return bar(pt);
}
int bar(pt)
struct foobar *pt;
{
return 0;
}
The types of the parameters to foo() and bar() are distinct. In
pre-prototype days, there would be no way for the compiler to warn you about
it, but they are distinct types nonetheless.
--
Kenneth Brody |
|
| Back to top |
|
|
Nick Bowler
Guest
|
| Posted: Mon Jun 25, 2012 5:31 pm Post subject: Re: C scope and struct definitions |
|
|
On Sat, 23 Jun 2012 22:51:56 -0400, James Kuyper wrote:
| Quote: | 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. |
|
| Back to top |
|
|
Tim Rentsch
Guest
|
| Posted: Mon Jun 25, 2012 7:22 pm Post subject: Re: C scope and struct definitions |
|
|
Kenneth Brody <kenbrody (AT) spamcop (DOT) net> writes:
| Quote: | On 6/24/2012 12:23 PM, Tim Rentsch wrote:
[...]
Surely not a historical accident, because prototypes didn't exist
in C before it was standardized.
[...]
Also, the behavior in C probably was chosen to match the behavior
in C++, from whence prototypes were derived. So this is really
a C++ question rather than a C question (1/2 .
I don't see this as a strictly prototype-related question. It's just
that prototypes give the compiler an opportunity to warn you about it
if necessary.
For example:
int foo(pt)
struct foobar *pt;
{
return bar(pt);
}
int bar(pt)
struct foobar *pt;
{
return 0;
}
The types of the parameters to foo() and bar() are distinct. In
pre-prototype days, there would be no way for the compiler to warn you
about it, but they are distinct types nonetheless.
|
The two cases (ie, prototypes and old-style definitions) are
different in some other important ways, but let me ignore that for
the moment.
The key issue here is not whether the types are distinct but how
the function calls are required to behave. In pre-ANSI compilers,
I expect calls between these functions would work just fine,
because the (unstated) type rules were more lax. The question
about type compability didn't come up in those compilers, because
type compatibility wasn't a well-defined notion in K&R C. So, even
though you are right that prototypes need not be involved, it still
is true that the problems related to using previously undeclared
struct types in parameter declarations did not exist in pre-ANSI C,
which is basically the same as saying it did not exist in C before
it had prototypes. It's not entirely a coincidence that prototypes
and more exact type rules were introduced into C at the same time,
namely when it was first standardized.
So I think your point may be technically right, but it doesn't
change the point I was making about lack of historical precedent. |
|
| Back to top |
|
|
Tim Rentsch
Guest
|
| Posted: Mon Jun 25, 2012 7:43 pm Post subject: Re: C scope and struct definitions |
|
|
James Kuyper <jameskuyper (AT) verizon (DOT) net> writes:
| Quote: | 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.)
| Quote: | 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. |
|
| Back to top |
|
|
Jens Gustedt
Guest
|
| Posted: Tue Jun 26, 2012 9:44 am Post subject: Re: C scope and struct definitions |
|
|
Am 25.06.2012 20:46, schrieb James Kuyper:
| Quote: | 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.
| Quote: | (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.
| Quote: | That being said, breaking the above program may be a good thing.
I think so.
|
definitively
Jens |
|
| Back to top |
|
|
Jens Gustedt
Guest
|
| Posted: Tue Jun 26, 2012 7:21 pm Post subject: Re: C scope and struct definitions |
|
|
Am 26.06.2012 22:08, schrieb Alan Curry:
| Quote: | Scope is the boundary of a variable's existence at compile time.
|
of the identifier, to be precise
| Quote: | 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).
|
no, not at all. Lifetime is a property of objects, not of
variables. Many objects aren't related to any kind of scope, are not
related to variables or identifiers, namely those that are allocated
through malloc and friends.
An object that is designated by a local variable in some function
scope, can be accessed in many scopes that are not related to the
scope of definition, simply by passing the address to another
function.
If a function is called recursively, many "incarnations" of the same
variable exist simultaneously. Multiple lifetimes correspond to a
single syntactical scope.
Jens |
|
| Back to top |
|
|
Eric Sosman
Guest
|
| Posted: Tue Jun 26, 2012 7:59 pm Post subject: Re: C scope and struct definitions |
|
|
On 6/26/2012 4:08 PM, Alan Curry wrote:
| Quote: | In article <Nv6dnf0QUclO4HXSnZ2dnUVZ_vadnZ2d (AT) bestweb (DOT) net>,
Kenneth Brody <kenbrody (AT) spamcop (DOT) net> wrote:
On 6/24/2012 1:40 AM, Alan Curry wrote:
In article <lny5nd78em.fsf (AT) nuthaus (DOT) mib.org>,
Keith Thompson <kst-u (AT) mib (DOT) org> wrote:
pacman (AT) kosh (DOT) dhis.org (Alan Curry) writes:
[...]
Variable scopes make sense because the object named by the variable doesn't
exist until the function is called. A type isn't an object.
Are you conflating scope and lifetime?
Are you seriously saying they aren't (or shouldn't be) closely tied together?
I don't think they are tied together at all.
I was going to say that the exception would be that a lifetime can't extend
beyond a scope, but then thought of:
void foo(void)
{
static struct bar { ... } foobar;
...
}
Can you give an example where scope and lifetime are (or "should") be
closely tied together?
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
usage not found in section 6.2.1 of the Standard, which defines what
the word means in C. One of the first things you'll notice about
that section is that the title is not "Scopes of variables" but
"Scopes of identifiers." Scope is not a property of variables, but
a property of identifiers. (In fact, the word "variable" does not
appear even once in that section.)
| Quote: | 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.)
--
Eric Sosman
esosman@ieee-dot-org.invalid |
|
| Back to top |
|
|
Eric Sosman
Guest
|
| Posted: Tue Jun 26, 2012 8:05 pm Post subject: Re: C scope and struct definitions |
|
|
On 6/26/2012 5:47 PM, Alan Curry wrote:
| Quote: | In article <4FEA27EC.70201 (AT) loria (DOT) fr>,
Jens Gustedt <jens.gustedt (AT) loria (DOT) fr> wrote:
Am 26.06.2012 22:08, schrieb Alan Curry:
Scope is the boundary of a variable's existence at compile time.
of the identifier, to be precise
If you're too precise about everything, you miss a lot. Like the fact that
"the variable exists here" is a reasonable way to describe the name being in
scope, and it's also a way to describe the memory region being allocated. Try
to actually *think* about it, instead of rephrasing it in language-lawyer
terms.
|
One thing you miss a lot of is opportunity to be misunderstood.
There's glory for you!
--
Eric Sosman
esosman@ieee-dot-org.invalid |
|
| Back to top |
|
|
Alan Curry
Guest
|
| Posted: Tue Jun 26, 2012 8:08 pm Post subject: Re: C scope and struct definitions |
|
|
In article <Nv6dnf0QUclO4HXSnZ2dnUVZ_vadnZ2d (AT) bestweb (DOT) net>,
Kenneth Brody <kenbrody (AT) spamcop (DOT) net> wrote:
| Quote: | On 6/24/2012 1:40 AM, Alan Curry wrote:
In article <lny5nd78em.fsf (AT) nuthaus (DOT) mib.org>,
Keith Thompson <kst-u (AT) mib (DOT) org> wrote:
pacman (AT) kosh (DOT) dhis.org (Alan Curry) writes:
[...]
Variable scopes make sense because the object named by the variable doesn't
exist until the function is called. A type isn't an object.
Are you conflating scope and lifetime?
Are you seriously saying they aren't (or shouldn't be) closely tied together?
I don't think they are tied together at all.
I was going to say that the exception would be that a lifetime can't extend
beyond a scope, but then thought of:
void foo(void)
{
static struct bar { ... } foobar;
...
}
Can you give an example where scope and lifetime are (or "should") be
closely tied together?
|
Scope is the boundary of a variable's existence at compile time. 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.
static locals break that nice symmetry between compile time and runtime, in
the same way as the localized type definitions we've been talking about. And
they are inessential for the same reason: if you pull foobar out of the
function and give it a unique name, everything works exactly the same.
This is not an attack, a proposal, or a demand for anyone to stop using
"static". I know that's how things get interpreted by the more aggressive
posters here. So calm down everybody, not everything has to be a fight. I
have lots of local static variables in my own code. They don't feel as weird
to me as local types for some reason I can't explain.
Between nested functions, static local variables, and locally-scoped struct
definitions, the only one whose absence couldn't be easily worked around is
the one that's actually absent.
--
Alan Curry |
|
| Back to top |
|
|
Eric Sosman
Guest
|
| Posted: Tue Jun 26, 2012 8:33 pm Post subject: Re: C scope and struct definitions |
|
|
On 6/26/2012 6:18 PM, Alan Curry wrote:
| Quote: | 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.
| Quote: | 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.)
| Quote: | 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 |
|
| Back to top |
|
|
Keith Thompson
Guest
|
| Posted: Tue Jun 26, 2012 9:45 pm Post subject: Re: C scope and struct definitions |
|
|
Jens Gustedt <jens.gustedt (AT) loria (DOT) fr> writes:
| Quote: | Am 26.06.2012 22:08, schrieb Alan Curry:
Scope is the boundary of a variable's existence at compile time.
of the identifier, to be precise
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).
no, not at all. Lifetime is a property of objects, not of
variables. Many objects aren't related to any kind of scope, are not
related to variables or identifiers, namely those that are allocated
through malloc and friends.
[...] |
What exactly do you mean by "variable"?
I tend to think of it as an informal word referring to a (probably
non-const) object that has a name, but I don't think that's how you're
using it.
I'm not saying your usage is wrong, but since the C standard doesn't
define "variable" I really can't tell what you mean by it.
--
Keith Thompson (The_Other_Keith) kst-u (AT) mib (DOT) 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" |
|
| Back to top |
|
|
Alan Curry
Guest
|
| Posted: Tue Jun 26, 2012 9:47 pm Post subject: Re: C scope and struct definitions |
|
|
In article <4FEA27EC.70201 (AT) loria (DOT) fr>,
Jens Gustedt <jens.gustedt (AT) loria (DOT) fr> wrote:
| Quote: | Am 26.06.2012 22:08, schrieb Alan Curry:
Scope is the boundary of a variable's existence at compile time.
of the identifier, to be precise
|
If you're too precise about everything, you miss a lot. Like the fact that
"the variable exists here" is a reasonable way to describe the name being in
scope, and it's also a way to describe the memory region being allocated. Try
to actually *think* about it, instead of rephrasing it in language-lawyer
terms.
--
Alan Curry |
|
| Back to top |
|
|
Alan Curry
Guest
|
| Posted: Tue Jun 26, 2012 10:18 pm Post subject: Re: C scope and struct definitions |
|
|
In article <jsdbb6$t43$1@dont-email.me>,
Eric Sosman <esosman@ieee-dot-org.invalid> wrote:
| Quote: | 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.
| Quote: | usage not found in section 6.2.1 of the Standard, which defines what
the word means in C. One of the first things you'll notice about
that section is that the title is not "Scopes of variables" but
"Scopes of identifiers." Scope is not a property of variables, but
a property of identifiers. (In fact, the word "variable" does not
appear even once in that section.)
|
The more you have to rely on word-for-word quotations from an authoritative
source, the less conceptual understanding you demonstrate.
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.
| Quote: |
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.
--
Alan Curry |
|
| Back to top |
|
|
Keith Thompson
Guest
|
| Posted: Tue Jun 26, 2012 10:22 pm Post subject: Re: C scope and struct definitions |
|
|
pacman (AT) kosh (DOT) dhis.org (Alan Curry) writes:
[...]
| Quote: | 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 (AT) mib (DOT) 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" |
|
| Back to top |
|
|
Powered by phpBB © 2001, 2006 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
