Returning address of local variable

[Keith Thompson]

[...]
(I think it depends on whether you mean lexical or dynamic scope.)

The phrases "lexical scope" and "dynamic scope" appear
nowhere in the Standard.

The behaviour being discussed is not unique to C, so it seemed
acceptable to use more informal terms, especially as we aren't in
comp.std.c.

Even informally, the word "scope" refers to visibility. Some
languages have dynamic scope; C does not. The relevant distinction
here is between scope and lifetime, not between different kinds of
scope.

I'm guessing most people reading this group aren't intimately
acquainted with Concepts VI:2:1.

That would be C99 6.2.1 (yes, I know you're making a joke about
"chapter and verse"). But I'd say that's all the more reason to use
correct and consistent terminology. Those of us are familiar with
6.2.1 know what "scope" means in C.

I've just realised I'm working on a language where it is possible to
access main.a (and so on) from anywhere else. Now I have to work out
(1) how to implement it and (2) what it actually means (bearing in
mind there might be multiple main.a's in existence).

<OT>And for functions other than main, you need to work out what to do
if there are *no* func.a's in existence. Providing visibility to a
function's local variables from outside that function doesn't seem
like a particularly good idea, but perhaps it makes sense in
context.</OT>

 

[Wolfgang Draxinger]

It *does* get "destroyed," in the sense that its lifetime
comes to an end (6.2.4p2,p4).

To me the term "destroyed" means, that the object is actively
de-initialized. In the case of C this doesn't happen, if a variable goes
out of scope, the whole concept of destruction is absent from plain C. Any
deinitialization must be done manually.

In other languages, C++ for example, if the object's class defines a
destructor, when a auto storage variable of that type goes out of scope
this destructor is called.


Wolfgang

 

[Wolfgang Draxinger]

That would be C99 6.2.1 (yes, I know you're making a joke about
"chapter and verse").  But I'd say that's all the more reason to use
correct and consistent terminology.  Those of us are familiar with
6.2.1 know what "scope" means in C.

<nitpicking mode="ultra">
And in this discussion 6.2.4-5 is to be mentioned, too.
</nitpicking>


Wolfgang

 

[BartC]

<OT>And for functions other than main, you need to work out what to do
if there are *no* func.a's in existence. Providing visibility to a
function's local variables from outside that function doesn't seem
like a particularly good idea, but perhaps it makes sense in
context

It sort of makes sense for local static variables, and perhaps things like
named constants. Accessing local auto variables makes less sense and is
difficult to do (apart from deciding which of the 0 to N invocations of
'func' to use) so I will probably prohibit that.

 

[Eric Sosman]

The behaviour being discussed is not unique to C, [...]

This opinion seems insupportable, given the context of
the original poster's question. He exhibited C source, noted
that it contravened the rules of C, and asked whether the
observed behavior was evidence of a bug in his C compiler.
I do not see how his question can be interpreted as applying
to any language other than C.

 

[Keith Thompson]

It sort of makes sense for local static variables, and perhaps things
like named constants. Accessing local auto variables makes less sense
and is difficult to do (apart from deciding which of the 0 to N
invocations of 'func' to use) so I will probably prohibit that.

Here's my suggestion. If you want a variable to be visible outside
the function in which it's declared, declare it outside the function.

 

[Nick Keighley]

Eric Sosman wrote:

To me the term "destroyed" means, that the object is actively
de-initialized.

Only because you've been exposed to C++. A reasonable meaning for
"destroyed" would be "ceases to exist". It seems reasonable to think
of it as being logically inaccessable. To access it invokes
Undefined Behaviour. It would be reasonable (though expensive on
real-world hardware) to unmap the memory when the variable
went out of scope.

 

[BartC]

Here's my suggestion. If you want a variable to be visible outside
the function in which it's declared, declare it outside the function.

That's fine, but I'm sure use can be made of the idea. Suppose a bunch of
functions each maintained some sort of status (or any other attribute, even
a documentation string), and you wanted to find out what that status was,
then assuming you used "." as a name resolver:

if (fopen.status==...)
if (fread.status==...)

The alternative is a set of globals (which I understand are frowned upon),
or a special entry point into the function to retrieve this value (which
complicates it's interface).

 

[BartC]

The behaviour being discussed is not unique to C, [...]

This opinion seems insupportable, given the context of
the original poster's question. He exhibited C source, noted
that it contravened the rules of C, and asked whether the
observed behavior was evidence of a bug in his C compiler.
I do not see how his question can be interpreted as applying
to any language other than C.

Nevertheless, this sort behaviour (specifically of Beej's example) /is/
common. The C standard mentions few other languages but they do exist and
are sometimes useful to compare with.