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 1 of 4  [1] 2 3 4  Next page →

#22548 — C scope and struct definitions

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.

Something like:

     int foo(struct bar *);

     ...

     int foo(struct bar *baz)
         {
         ...
         }

The compiler decided that the "struct bar" in one place was not the same 
"struct bar" in the other place.

The solution, of course, was to add a simple "struct bar;" at file scope 
prior to its first reference.

I can't duplicate any error right now, though a simple test does give me a 
warning:

     'bar' : named type definition in parentheses

Was the compiler correct to treat the two references as distinct?  If a 
struct definition is not visible at the time, can a reference to a pointer 
to that struct be a different type than another one to the same named struct?

Again, I don't remember the exact details, as it was some time ago.

-- 
Kenneth Brody

[toc] | [next] | [standalone]

#22551

On 6/22/2012 1:30 PM, Kenneth Brody wrote:
> 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.
>
> Something like:
>
>      int foo(struct bar *);
>
>      ...
>
>      int foo(struct bar *baz)
>          {
>          ...
>          }
>
> The compiler decided that the "struct bar" in one place was not the same
> "struct bar" in the other place.
>
> The solution, of course, was to add a simple "struct bar;" at file scope
> prior to its first reference.
>
> I can't duplicate any error right now, though a simple test does give me
> a warning:
>
>      'bar' : named type definition in parentheses
>
> Was the compiler correct to treat the two references as distinct?  If a
> struct definition is not visible at the time, can a reference to a
> pointer to that struct be a different type than another one to the same
> named struct?
>
> Again, I don't remember the exact details, as it was some time ago.

     The compiler was right.  The relevant text is in 6.2.1p4:

	"[...] If the declarator or type specifier that declares
	the identifier appears inside a block or within the list
	of parameter declarations in a function definition, the
	identifier has block scope, which terminates at the end
	of the associated block. If the declarator or type specifier
	that declares the identifier appears within the list of
	parameter declarations in a function prototype (not part
	of a function definition), the identifier has function
	prototype scope, which terminates at the end of the
	function declarator. [...]"

So: The scope of `struct bar' in the first part of your example
ends where the prototype does (second sentence), while that of
`struct bar' in the second part is confined to the function body
(first sentence).  The scopes do not overlap, so the two uses of
`struct bar' are distinct.

     See also FAQ Question 11.5.

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

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

#22562

In article <js2buv$evv$1@dont-email.me>,
Eric Sosman  <esosman@ieee-dot-org.invalid> wrote:
>On 6/22/2012 1:30 PM, Kenneth Brody wrote:
>>
>>      int foo(struct bar *);
>>
>>      ...
>>
>>      int foo(struct bar *baz)
>>          {
>>          ...
>>          }
>>
>> The compiler decided that the "struct bar" in one place was not the same
>> "struct bar" in the other place.
[...]
>
>     The compiler was right.  The relevant text is in 6.2.1p4:

But is the compiler right for a real reason, or is it just a continuation of
a historical accident? Why would you ever want this behavior?

I don't even see why you'd ever want any scope for a struct type other than
"from here to the end of the file". Types are global things.

-- 
Alan Curry

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

#22563

pacman@kosh.dhis.org (Alan Curry) writes:

> I don't even see why you'd ever want any scope for a struct type other than
> "from here to the end of the file". Types are global things.

Occasionally I do declare and use a struct type within a
function.  I'd like that to continue working.

I do agree that the behavior of struct types defined within a
function prototype is surprising and not useful.

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

#22568

On 6/22/2012 6:40 PM, Alan Curry wrote:
> In article <js2buv$evv$1@dont-email.me>,
> Eric Sosman  <esosman@ieee-dot-org.invalid> wrote:
>> On 6/22/2012 1:30 PM, Kenneth Brody wrote:
>>>
>>>       int foo(struct bar *);
>>>
>>>       ...
>>>
>>>       int foo(struct bar *baz)
>>>           {
>>>           ...
>>>           }
>>>
>>> The compiler decided that the "struct bar" in one place was not the same
>>> "struct bar" in the other place.
> [...]
>>
>>      The compiler was right.  The relevant text is in 6.2.1p4:
>
> But is the compiler right for a real reason, or is it just a continuation of
> a historical accident? Why would you ever want this behavior?

     The Rationale sheds no light my tired old eyes can see.  You
are welcome to read it for yourself.  (Also, if you think the
normative text of the formal definition of the C language does not
qualify as "a real reason," well ...)

> I don't even see why you'd ever want any scope for a struct type other than
> "from here to the end of the file". Types are global things.

     Say, what?

	void f(void) {
	    static const struct foo {
	        const char *roman;
	        int decimal;
	    } table[] = { { "I", 1 }, { "II", 2 }, ... };
	    ...
	}

	void g(void) {
	    struct foo {
	        double payload;
	        struct foo *next;
	    } *head, *p, *q;
	    ...
	}

Do you seriously maintain that these two `struct foo' types
should conflict with each other?  If so, why?  Explain why you
feel it is Wrong for a function to declare and use its own
private type for its own purposes, and why f() should have to
worry about what g() does in the privacy of its own block.

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

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

#22586

In article <js32rk$siv$1@dont-email.me>,
Eric Sosman  <esosman@ieee-dot-org.invalid> wrote:
>On 6/22/2012 6:40 PM, Alan Curry wrote:
>>
>> But is the compiler right for a real reason, or is it just a continuation of
>> a historical accident? Why would you ever want this behavior?
>
>     The Rationale sheds no light my tired old eyes can see.  You
>are welcome to read it for yourself.  (Also, if you think the
>normative text of the formal definition of the C language does not
>qualify as "a real reason," well ...)

The standard was supposed to codify existing practice. A real reason would
have to come from before standardization. Was there a real reason for the
existence of such a small, useless scope?

>
>> I don't even see why you'd ever want any scope for a struct type other than
>> "from here to the end of the file". Types are global things.
>
>     Say, what?
>
>	void f(void) {
>	    static const struct foo {
>	        const char *roman;
>	        int decimal;
>	    } table[] = { { "I", 1 }, { "II", 2 }, ... };
>	    ...
>	}
>
>	void g(void) {
>	    struct foo {
>	        double payload;
>	        struct foo *next;
>	    } *head, *p, *q;
>	    ...
>	}
>
>Do you seriously maintain that these two `struct foo' types
>should conflict with each other?  If so, why?  Explain why you
>feel it is Wrong for a function to declare and use its own
>private type for its own purposes, and why f() should have to
>worry about what g() does in the privacy of its own block.

I don't think we'd be losing anything if those declarations were simply
illegal. Declare your structs before your functions. They aren't variables.

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.

If you really have two different structs with the same name in one program,
you should want to be warned about it. It's a sign that you should either
merge them (if they are different representations of the same concept) or
rename them.

Variables, functions, and constant data are all defined with reference to
types. Types are the most fundamental entities in a program. They deserve
globally unique names.

-- 
Alan Curry

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

#22590

pacman@kosh.dhis.org (Alan Curry) writes:
> In article <js32rk$siv$1@dont-email.me>,
> Eric Sosman  <esosman@ieee-dot-org.invalid> wrote:
>>On 6/22/2012 6:40 PM, Alan Curry wrote:
>>>
>>> But is the compiler right for a real reason, or is it just a
>>> continuation of a historical accident? Why would you ever want this
>>> behavior?
>>
>>     The Rationale sheds no light my tired old eyes can see.  You
>>are welcome to read it for yourself.  (Also, if you think the
>>normative text of the formal definition of the C language does not
>>qualify as "a real reason," well ...)
>
> The standard was supposed to codify existing practice. A real reason
> would have to come from before standardization. Was there a real
> reason for the existence of such a small, useless scope?

Yes: it's not useless.

>>
>>> I don't even see why you'd ever want any scope for a struct type other than
>>> "from here to the end of the file". Types are global things.
>>
>>     Say, what?
>>
>>	void f(void) {
>>	    static const struct foo {
>>	        const char *roman;
>>	        int decimal;
>>	    } table[] = { { "I", 1 }, { "II", 2 }, ... };
>>	    ...
>>	}
>>
>>	void g(void) {
>>	    struct foo {
>>	        double payload;
>>	        struct foo *next;
>>	    } *head, *p, *q;
>>	    ...
>>	}
>>
>>Do you seriously maintain that these two `struct foo' types
>>should conflict with each other?  If so, why?  Explain why you
>>feel it is Wrong for a function to declare and use its own
>>private type for its own purposes, and why f() should have to
>>worry about what g() does in the privacy of its own block.
>
> I don't think we'd be losing anything if those declarations were simply
> illegal. Declare your structs before your functions. They aren't variables.

We'd lose backward compatibility; it would break existing code. I've
seen plenty of small programs that define types inside main (or
would you make main a special case?).

Nothing stops you from declaring your structs at file scope if you
want to, and I agree that it's *usually* the best thing to do.

But if a given type happens to be used only inside one function,
or even inside one block, the language allows you to declare it
there without polluting the rest of the program's namespace.

> 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.

We're talking about scope, not lifetime.  Types don't have lifetime,
but like any other declared entity, they do have scope (the region
of source code over in they're visible).

The scope rules for types are consistent with the scope rules for
objects. This consistency makes the language simpler, and has no
real cost that I can see. Again, if you don't want to declare types
at block scope, then by all means don't.

[...]

-- 
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]

#22684

On 06/23/2012 07:18 PM, Keith Thompson wrote:
> pacman@kosh.dhis.org (Alan Curry) writes:
>> In article <js32rk$siv$1@dont-email.me>,
>> Eric Sosman  <esosman@ieee-dot-org.invalid> wrote:
>>> On 6/22/2012 6:40 PM, Alan Curry wrote:
>>>>
>>>> But is the compiler right for a real reason, or is it just a
>>>> continuation of a historical accident? Why would you ever want this
>>>> behavior?
>>>
>>>     The Rationale sheds no light my tired old eyes can see.  You
>>> are welcome to read it for yourself.  (Also, if you think the
>>> normative text of the formal definition of the C language does not
>>> qualify as "a real reason," well ...)
>>
>> The standard was supposed to codify existing practice. A real reason
>> would have to come from before standardization. Was there a real
>> reason for the existence of such a small, useless scope?
> 
> Yes: it's not useless.

While other issues have been discussed in this thread, the original
context was that the very first declaration of a struct type in a given
translation unit has function prototype scope. How is that useful? The
only other place where such a struct type could be used is in other
declarations in the same function prototype. That imposes some serious
restrictions on the ability to call the function, or even to store a
pointer to the function.

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

#22700

James Kuyper <jameskuyper@verizon.net> writes:
> On 06/23/2012 07:18 PM, Keith Thompson wrote:
>> pacman@kosh.dhis.org (Alan Curry) writes:
>>> In article <js32rk$siv$1@dont-email.me>,
>>> Eric Sosman  <esosman@ieee-dot-org.invalid> wrote:
>>>> On 6/22/2012 6:40 PM, Alan Curry wrote:
>>>>>
>>>>> But is the compiler right for a real reason, or is it just a
>>>>> continuation of a historical accident? Why would you ever want this
>>>>> behavior?
>>>>
>>>>     The Rationale sheds no light my tired old eyes can see.  You
>>>> are welcome to read it for yourself.  (Also, if you think the
>>>> normative text of the formal definition of the C language does not
>>>> qualify as "a real reason," well ...)
>>>
>>> The standard was supposed to codify existing practice. A real reason
>>> would have to come from before standardization. Was there a real
>>> reason for the existence of such a small, useless scope?
>> 
>> Yes: it's not useless.
>
> While other issues have been discussed in this thread, the original
> context was that the very first declaration of a struct type in a given
> translation unit has function prototype scope. How is that useful? The
> only other place where such a struct type could be used is in other
> declarations in the same function prototype. That imposes some serious
> restrictions on the ability to call the function, or even to store a
> pointer to the function.

I agree that struct definitions in prototype scope are not useful.
C++ bans them, and as I've said elsethread I wouldn't mind if C
did so as well.

I was referring to struct definitions at block scope.

-- 
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]

#22591

On 6/23/2012 6:06 PM, Alan Curry wrote:
> In article <js32rk$siv$1@dont-email.me>,
> Eric Sosman  <esosman@ieee-dot-org.invalid> wrote:
>> On 6/22/2012 6:40 PM, Alan Curry wrote:
>>>
>>> But is the compiler right for a real reason, or is it just a continuation of
>>> a historical accident? Why would you ever want this behavior?
>>
>>      The Rationale sheds no light my tired old eyes can see.  You
>> are welcome to read it for yourself.  (Also, if you think the
>> normative text of the formal definition of the C language does not
>> qualify as "a real reason," well ...)
>
> The standard was supposed to codify existing practice. A real reason would
> have to come from before standardization. Was there a real reason for the
> existence of such a small, useless scope?

     Note that existing practice had no notion of prototypes at all,
so the issue of "prototype scope" simply didn't exist.  (The ANSI
Standard invented other things new to the language, too: `void',
for example.)

     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?

>>
>>> I don't even see why you'd ever want any scope for a struct type other than
>>> "from here to the end of the file". Types are global things.
>>
>>      Say, what?
>>
>> 	void f(void) {
>> 	    static const struct foo {
>> 	        const char *roman;
>> 	        int decimal;
>> 	    } table[] = { { "I", 1 }, { "II", 2 }, ... };
>> 	    ...
>> 	}
>>
>> 	void g(void) {
>> 	    struct foo {
>> 	        double payload;
>> 	        struct foo *next;
>> 	    } *head, *p, *q;
>> 	    ...
>> 	}
>>
>> Do you seriously maintain that these two `struct foo' types
>> should conflict with each other?  If so, why?  Explain why you
>> feel it is Wrong for a function to declare and use its own
>> private type for its own purposes, and why f() should have to
>> worry about what g() does in the privacy of its own block.
>
> I don't think we'd be losing anything if those declarations were simply
> illegal. Declare your structs before your functions. They aren't variables.

     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.

> 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?

> If you really have two different structs with the same name in one program,
> you should want to be warned about it. It's a sign that you should either
> merge them (if they are different representations of the same concept) or
> rename them.

     Bah.

> Variables, functions, and constant data are all defined with reference to
> types. Types are the most fundamental entities in a program. They deserve
> globally unique names.

     I'm with you, up to the antepenultimate word.  Why should a
type declared in the bowels of some function in some library I don't
even have source to be "global?"  How shall I select my identifiers
to ensure that no third party's library bollixes them?

     If you want "global," go back to BASICs.  (By which I mean
Kemeny and Kurtz, not MS.)

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

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

#22592

In article <js5l0m$64l$1@dont-email.me>,
Eric Sosman  <esosman@ieee-dot-org.invalid> wrote:
>On 6/23/2012 6:06 PM, Alan Curry wrote:
>> In article <js32rk$siv$1@dont-email.me>,
>> Eric Sosman  <esosman@ieee-dot-org.invalid> wrote:
>>> On 6/22/2012 6:40 PM, Alan Curry wrote:
>>>>
>>>> But is the compiler right for a real reason, or is it just a continuation of
>>>> a historical accident? Why would you ever want this behavior?
>>>
>>>      The Rationale sheds no light my tired old eyes can see.  You
>>> are welcome to read it for yourself.  (Also, if you think the
>>> normative text of the formal definition of the C language does not
>>> qualify as "a real reason," well ...)
>>
>> The standard was supposed to codify existing practice. A real reason would
>> have to come from before standardization. Was there a real reason for the
>> existence of such a small, useless scope?
>
>     Note that existing practice had no notion of prototypes at all,
>so the issue of "prototype scope" simply didn't exist.  (The ANSI
>Standard invented other things new to the language, too: `void',
>for example.)
>
>     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.

Those names should simply be omitted, and it would be a good thing if they
weren't allowed either. They serve no purpose and cause problems in header
files when one header defines a macro that another header uses as an argument
name in a prototype.

We are allowed to use the intelligent comment markers /* */ in C, not just
the dumb // to-end-of-line kind, so you can say

  void f(char * /*p*/, double * /*q*/);

if the parameter names are meant to be documentation.

Anyway, putting type names and variable names into a single category and
calling them "identifiers" is a false generalization. It works at the
technical level for the compiler implementor I guess, but besides that what's
the reason for lumping them together and insisting that they behave the same?
If you can't explain it without the word "identifier" then there is no
reason, it's just a thought process that's being misled by a bit of escaped
compiler-writer's jargon.

>>
>> I don't think we'd be losing anything if those declarations were simply
>> illegal. Declare your structs before your functions. They aren't variables.
>
>     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.

The same could be said for a function that's only called by one other
function. Should we have nested functions then?

>
>> 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?

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.

>> Variables, functions, and constant data are all defined with reference to
>> types. Types are the most fundamental entities in a program. They deserve
>> globally unique names.
>
>     I'm with you, up to the antepenultimate word.  Why should a
>type declared in the bowels of some function in some library I don't
>even have source to be "global?"  How shall I select my identifiers
>to ensure that no third party's library bollixes them?
>
>     If you want "global," go back to BASICs.  (By which I mean
>Kemeny and Kurtz, not MS.)

You don't have to take "global" that far. Third party libraries occupy
separate globes. Uniqueness within a source file is a reasonable requirement.
Uniqueness within a set of files that are compiled at the same time would be
a good bonus check.

-- 
Alan Curry

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

#22594

On 6/23/2012 8:56 PM, Alan Curry wrote:
> In article <js5l0m$64l$1@dont-email.me>,
> Eric Sosman  <esosman@ieee-dot-org.invalid> 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.
>
> Those names should simply be omitted, and it would be a good thing if they
> weren't allowed either. They serve no purpose and cause problems in header
> files when one header defines a macro that another header uses as an argument
> name in a prototype.
>
> We are allowed to use the intelligent comment markers /* */ in C, not just
> the dumb // to-end-of-line kind, so you can say
>
>    void f(char * /*p*/, double * /*q*/);
>
> if the parameter names are meant to be documentation.

     So your argument against prototype scope boils down to "C's
syntax should be different."  Okay, fine; tastes differ.  But two
points stand out: First, that *given* the decision to allow
identifiers in prototypes, prototype scope follows as a practical
necessity.  Second, that if identifiers were forbidden in prototypes,
then the entire thread would never have started in the first place
and so the whole argument evaporates.

> Anyway, putting type names and variable names into a single category and
> calling them "identifiers" is a false generalization.

     If type names are somehow segregated from names-of-other-things,
does that mean

	double int = 42;
	long * double void(short long);
	struct struct { long *union; char enum; };

... are to your liking?

     (In my early youth I was weaned on a language that had no
reserved words at all, a language in which `DO 10 I = (1 , 10)'
was perfectly legal and *not* a loop construct.  For a while I
esteemed this as a sort of Purity.  I got over it.)

     But, hey: Back to the beginning.  You asked whether a compiler
that obeyed 6.2.1p4 did so quote "for a real reason" end quote.
The answer to your question is "Yes," because 6.2.1p4 dictates
how the compiler must behave.  Debate about whether 6.2.1p4 ought
to have said something else should be between you and X3J11, not
between you and me.

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

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

#22601

In article <js5rl3$5pf$1@dont-email.me>,
Eric Sosman  <esosman@ieee-dot-org.invalid> wrote:
>On 6/23/2012 8:56 PM, Alan Curry wrote:
>> In article <js5l0m$64l$1@dont-email.me>,
>
>> Anyway, putting type names and variable names into a single category and
>> calling them "identifiers" is a false generalization.
>
>     If type names are somehow segregated from names-of-other-things,
>does that mean
>
>	double int = 42;
>	long * double void(short long);
>	struct struct { long *union; char enum; };
>
>... are to your liking?

That would depend on whether it adds any conflicts to the grammar. If not, go
for it. We already allow this:

  struct foo { int i; };
  struct bar { short x,y; };
  typedef struct bar bar;
  static struct foo foo(bar foo, bar bar) { }

although it doesn't look very good. But this:

  int stat(const char *, struct stat *);

has been a respectable function for a long time.

>
>     (In my early youth I was weaned on a language that had no
>reserved words at all, a language in which `DO 10 I = (1 , 10)'
>was perfectly legal and *not* a loop construct.  For a while I
>esteemed this as a sort of Purity.  I got over it.)

I had the opposite of that experience, CBM BASIC. You can't have a variable
name that contains a keyword as a substring, because keywords are recognized
regardless of the lack of spacing around them. Luckily there are only 2
significant characters in a variable name so you'd never have a problem
unless you flamboyantly extended your variable names with insignificant
characters.

>
>     But, hey: Back to the beginning.  You asked whether a compiler
>that obeyed 6.2.1p4 did so quote "for a real reason" end quote.
>The answer to your question is "Yes," because 6.2.1p4 dictates
>how the compiler must behave.  Debate about whether 6.2.1p4 ought
>to have said something else should be between you and X3J11, not
>between you and me.

Standards aren't reasons at all. Official rationale is supplied for a few
things, the rest is just a record of decisions made and the reasons are found
elsewhere in history.

-- 
Alan Curry

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

#22653

On Sunday, June 24, 2012 7:03:06 AM UTC+1, Alan Curry wrote:

> I had the opposite of that experience, CBM BASIC. 

it shows

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

#22596

pacman@kosh.dhis.org (Alan Curry) writes:
> In article <js5l0m$64l$1@dont-email.me>,
> Eric Sosman  <esosman@ieee-dot-org.invalid> wrote:
>>On 6/23/2012 6:06 PM, Alan Curry wrote:
>>> In article <js32rk$siv$1@dont-email.me>,
>>> Eric Sosman  <esosman@ieee-dot-org.invalid> wrote:
>>>> On 6/22/2012 6:40 PM, Alan Curry wrote:
>>>>> But is the compiler right for a real reason, or is it just a
>>>>> continuation of a historical accident? Why would you ever want
>>>>> this behavior?
>>>>
>>>>      The Rationale sheds no light my tired old eyes can see.  You
>>>> are welcome to read it for yourself.  (Also, if you think the
>>>> normative text of the formal definition of the C language does not
>>>> qualify as "a real reason," well ...)
>>>
>>> The standard was supposed to codify existing practice. A real reason
>>> would have to come from before standardization. Was there a real
>>> reason for the existence of such a small, useless scope?
>>
>>     Note that existing practice had no notion of prototypes at all,
>>so the issue of "prototype scope" simply didn't exist.  (The ANSI
>>Standard invented other things new to the language, too: `void',
>>for example.)
>>
>>     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.
>
> Those names should simply be omitted, and it would be a good thing if they
> weren't allowed either. They serve no purpose and cause problems in header
> files when one header defines a macro that another header uses as an argument
> name in a prototype.
>
> We are allowed to use the intelligent comment markers /* */ in C, not just
> the dumb // to-end-of-line kind, so you can say
>
>   void f(char * /*p*/, double * /*q*/);
>
> if the parameter names are meant to be documentation.

Personally, I like having names for parameters in function declarations,
though I'm not pleased that they're ignored. My own preference would be
to make the names mandatory, and to require them to match the names used
in the function's definition.

So neither of is 100% satisfied with the way C is defined. I don't know
of anyone who is.

(I disagree with your characterization of // comments as "dumb", but I
won't get into that.)

> Anyway, putting type names and variable names into a single category and
> calling them "identifiers" is a false generalization. It works at the
> technical level for the compiler implementor I guess, but besides that what's
> the reason for lumping them together and insisting that they behave the same?
> If you can't explain it without the word "identifier" then there is no
> reason, it's just a thought process that's being misled by a bit of escaped
> compiler-writer's jargon.

I'd say it's a perfectly valid generalization. They *are* both
identifiers, and they follow the same scope rules.

You advocate treating type names as a special case with different scope
rules than other identifiers. That's a valid preference, but not one
that I share -- and not one that's consistent with C as it's currently
defined.

>>> I don't think we'd be losing anything if those declarations were simply
>>> illegal. Declare your structs before your functions. They aren't variables.
>>
>>     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.
>
> The same could be said for a function that's only called by one other
> function. Should we have nested functions then?

Many languages do have nested functions. What tends to make them
complicated is the need to define rules for accessing objects defined
in an outer function. I wouldn't strongly object to adding nested
functions to C (and gcc supports them as an extension), but I don't
think they're all that important; we've gotten along without them
for a very long time.

[...]

> 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?

[...]

-- 
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]

#22600

In article <lny5nd78em.fsf@nuthaus.mib.org>,
Keith Thompson  <kst-u@mib.org> wrote:
>pacman@kosh.dhis.org (Alan Curry) writes:
>
>> Anyway, putting type names and variable names into a single category and
>> calling them "identifiers" is a false generalization. It works at the
>> technical level for the compiler implementor I guess, but besides that what's
>> the reason for lumping them together and insisting that they behave the same?
>> If you can't explain it without the word "identifier" then there is no
>> reason, it's just a thought process that's being misled by a bit of escaped
>> compiler-writer's jargon.
>
>I'd say it's a perfectly valid generalization. They *are* both
>identifiers, and they follow the same scope rules.

They "are" both identifiers because the word "identifier" has been defined
that way. This is a circular argument. It doesn't prove that they belong
together in a class, just that they have been forced into one and an awkward
name has been slapped on it.

>
>You advocate treating type names as a special case with different scope
>rules than other identifiers. That's a valid preference, but not one
>that I share -- and not one that's consistent with C as it's currently
>defined.

More like no scope rules at all. Just a global table of types. (Global within
a single run of the compiler). Any time a new struct tag is seen, just add it
to the table and leave it there until the compiler exits. A type has an
existence inherently outside of any function because types are more
fundamental than functions.

>>
>> The same could be said for a function that's only called by one other
>> function. Should we have nested functions then?
>
>Many languages do have nested functions. What tends to make them
>complicated is the need to define rules for accessing objects defined
>in an outer function. I wouldn't strongly object to adding nested
>functions to C (and gcc supports them as an extension), but I don't
>think they're all that important; we've gotten along without them
>for a very long time.

That complication (closures) is a good reason to want nested functions. It
can be emulated without help from the compiler, but not easily. What's the
corresponding reason for wanting struct definitions inside a function?

>
>[...]
>
>> 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?

-- 
Alan Curry

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

#22603

Am 24.06.2012 07:40, schrieb Alan Curry:
>> Are you conflating scope and lifetime?
> 
> Are you seriously saying they aren't (or shouldn't be) closely tied together?

Hm, your question is vague, I don't see the point you want to make.

Lifetime is a property of objects that is determined at run time.
Objects, in particular those that are allocated through malloc and
friends, don't have a sensible notion of scope.

Scope is a property of identifiers that only makes sense at
compilation time. Identifiers don't have lifetime at all.

Jens

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

#22614

pacman@kosh.dhis.org (Alan Curry) writes:
> In article <lny5nd78em.fsf@nuthaus.mib.org>,
> Keith Thompson  <kst-u@mib.org> wrote:
>>pacman@kosh.dhis.org (Alan Curry) writes:
>>
>>> Anyway, putting type names and variable names into a single category
>>> and calling them "identifiers" is a false generalization. It works
>>> at the technical level for the compiler implementor I guess, but
>>> besides that what's the reason for lumping them together and
>>> insisting that they behave the same?  If you can't explain it
>>> without the word "identifier" then there is no reason, it's just a
>>> thought process that's being misled by a bit of escaped
>>> compiler-writer's jargon.
>>
>>I'd say it's a perfectly valid generalization. They *are* both
>>identifiers, and they follow the same scope rules.
>
> They "are" both identifiers because the word "identifier" has been
> defined that way. This is a circular argument. It doesn't prove that
> they belong together in a class, just that they have been forced into
> one and an awkward name has been slapped on it.

There's nothing arbitrary about the meaning of the word
"identifier". It's a syntactic construct, consisting of ... well,
you can read the grammar as well as I can.

You find it awkward that the same scope rules apply to identifers
that name objects and identifiers that name types.  I find it simple
and consistent, and I think most other people do as well.

I think I understand your point of view; you see types as a
fundamentally different kind of entity than objects, and you
don't think it makes sense for types to have anything other than
file scope.

My point of view is that the current scoping rules for type names
is sensible, that absolutely nothing prevents you from defining
all your types at file scope, and the restriction you suggest has
no great benefit, would make the language marginally more complex,
and would break existing code.

I'm not asking you to share my point of view, but can you understand
it?

>>You advocate treating type names as a special case with different scope
>>rules than other identifiers. That's a valid preference, but not one
>>that I share -- and not one that's consistent with C as it's currently
>>defined.
>
> More like no scope rules at all. Just a global table of types. (Global
> within a single run of the compiler). Any time a new struct tag is
> seen, just add it to the table and leave it there until the compiler
> exits. A type has an existence inherently outside of any function
> because types are more fundamental than functions.

So you deny the possibility that it might make sense to have a type
that's used only within one function.  that's fine, but if you don't
mind I'd rather you didn't try to impose that model on every C
programmer in the world.

>>> The same could be said for a function that's only called by one other
>>> function. Should we have nested functions then?
>>
>>Many languages do have nested functions. What tends to make them
>>complicated is the need to define rules for accessing objects defined
>>in an outer function. I wouldn't strongly object to adding nested
>>functions to C (and gcc supports them as an extension), but I don't
>>think they're all that important; we've gotten along without them
>>for a very long time.
>
> That complication (closures) is a good reason to want nested functions. It
> can be emulated without help from the compiler, but not easily. What's the
> corresponding reason for wanting struct definitions inside a function?

The point is that you can define a struct type that's only used within a
function, and that type is not made unnecessarily visible outside the
function.

>>
>>[...]
>>
>>> 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?

Yes.

Ok, they're tied together in some ways, but it's a loose tie. An
object declared inside a function has block scope, but its lifetime
can be either the nearest enclosing block *or* the entire execution
of the program, depending on whether it has the "static" keyword.
An object allocated by malloc() has allocated lifetime, but *no
scope* (since it doesn't have a name).

In the C language as it's currently defined, you can do exactly what
you want: define all types at file scope.  The change you propose
would not help you do that -- but it would break existing code.

Out of curiosity, are you talking about how you wish the language
had been defined in the first place, or are you proposing a change
to a future version of the language?

-- 
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]

#22639

In article <lnpq8o7fp7.fsf@nuthaus.mib.org>,
Keith Thompson  <kst-u@mib.org> wrote:
>
>Out of curiosity, are you talking about how you wish the language
>had been defined in the first place, or are you proposing a change
>to a future version of the language?

Neither. I only said that I don't think limited scopes for struct definitions
are useful, and there came a storm of disagreement. And also I speculated
that application of scoping rules to type names is a historical accident
rather than an intentionally designed feature, and I still don't know of any
evidence for or aginst that idea.

At least most of us agreed that a struct definition with "function prototype
scope" is a bad sign.

-- 
Alan Curry

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

#22642

On 6/24/2012 11:53 PM, Alan Curry wrote:
> In article <lnpq8o7fp7.fsf@nuthaus.mib.org>,
> Keith Thompson  <kst-u@mib.org> wrote:
>>
>> Out of curiosity, are you talking about how you wish the language
>> had been defined in the first place, or are you proposing a change
>> to a future version of the language?
>
> Neither. I only said that I don't think limited scopes for struct definitions
> are useful, and there came a storm of disagreement.

     If that's all you were saying, I apologize for any undue vehemence.
My ire was directed at the suggestion that conforming to the Standard
did not constitute a "real reason" for a compiler's behavior.

     This is not to say that I agree with your notion that UNlimited
scope for type names would be a good idea.  It goes against every
notion of encapsulation to insist that every block publish its own
internal workings for the rest of the world to see -- indeed, for the
rest of the world to be unable to avoid seeing.  But, hey: If that's
the way you want it, all you need do is write coding standards that
insist on file scope for all type definitions.

> And also I speculated
> that application of scoping rules to type names is a historical accident
> rather than an intentionally designed feature, and I still don't know of any
> evidence for or aginst that idea.

     So, as has been pointed out, your beef is with X3J11 and not with
anyone present.

> At least most of us agreed that a struct definition with "function prototype
> scope" is a bad sign.

     It's useless (which was where this thread started), and draws
a diagnostic from gcc and perhaps other compilers.  It's by no means
the only useless construct one can write in C; gcc will also diagnose
some of the others.  "Mommy! Mommy! C allows useless constructs!"
"Hush, my child, lest you awaken the colorless green ideas from
their furious sleep."

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

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

Page 1 of 4  [1] 2 3 4  Next page →

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

csiph-web