Is "scope" different from "visibility" ?

[TTroy]

I have a few questions about "scope" and "visibility," which seem like
two different things.

To me "visibility" of the name of a function or object is the actual
code that can use it in an actual program.
To me "scope" of the name of a function or object are the general rules
for the areas of a program that can through a declaration, have
"visibility."
[By "to me," I'm stating that this is how I use the terms.]

Ex:

Externally defined variables have global scope <- Scope rule

The variable int i; in main.c has visibility in both main.c and test.c
because there are declarations at the top of both files. <- describing
visibility


So it's as if, there are two steps to being able to access a function
name or object name - first the code must fall in the scope of the said
name, second the code must be in the visibility area of the said name
(via a declaration).

Am I right? Scope can be determined when an object or function is
defined, visibility can only be determined via declarations. If I'm
not right, then which two terms differentiate the ACTUAL VISIBILTY AREA
from the TOTAL POSSIBLE VISIBILITY AREA?

Also, say I have 2 source files main.c and second.c, and there is an
external variable defined at the top of main.c.

I only want to use this variable in 1 function in second.c, can I put
the extern declaration inside the function's braces (will this limit
others in second.c from accessing the variable?) ?

If the answer above is yes, then that is a better example of what I was
saying above. The scope would be all code in both files, while the
visibility would be all of main.c and just that function in second.c.

I haven't found enlightenment in any of the books or FAQs I've checked,
so any help would be really appreciated.

 

[Jack Klein]

I have a few questions about "scope" and "visibility," which seem like
two different things.

Scope is something defined by the C standard. "visibility" is not.

To me "visibility" of the name of a function or object is the actual
code that can use it in an actual program.

An object or function can only be referenced by name if it is in
scope.

To me "scope" of the name of a function or object are the general rules
for the areas of a program that can through a declaration, have
"visibility."
[By "to me," I'm stating that this is how I use the terms.]

But you are inventing a term not in the standard, and one that isn't
needed. An identifier must be in scope to be used. Period.

You are tangling up two actual C concepts, scope and linkage of
identifiers. But what you are calling visibility is nothing more or
less than scope.

Here is the text of paragraph 2 of section 6.2.1 Scopes of
identifiers, from the C standard:

"For each different entity that an identifier designates, the
identifier is visible (i.e., can be used) only within a region of
program text called its scope. Different entities designated
by the same identifier either have different scopes, or are in
different name spaces. There are four kinds of scopes: function, file,
block, and function prototype. (A function prototype is a declaration
of a function that declares the types of its parameters.)"

So an scope and visibility are the same thing.

Ex:

Externally defined variables have global scope <- Scope rule

No, there is no such thing as "global scope" in C. Externally defined
objects and functions have file scope. That scope extends from the
point of declaration (note that a definition is also a declaration) to
the end of the translation unit.

The other characteristic of objects defined at file scope is linkage.
They either have internal linkage, if the static keyword is part of
the definition, or external linkage by default if the static keyword
is not part of the definition.

But external linkage does not make an object or function usable by
name from another translation unit. That other translation unit must
have an external declaration of the object or function in scope when
it attempts to use it.

The variable int i; in main.c has visibility in both main.c and test.c
because there are declarations at the top of both files. <- describing
visibility

If the declaration:

int i;

....appears at file scope in two different translation units that are
part of the same program, the behavior is undefined, because each of
these declarations is a 'tentative definition' that becomes an
external definition at the end of the translation unit.

So it's as if, there are two steps to being able to access a function
name or object name - first the code must fall in the scope of the said
name, second the code must be in the visibility area of the said name
(via a declaration).

No, what you are calling visibility is nothing more or less than
scope.

Am I right? Scope can be determined when an object or function is
defined, visibility can only be determined via declarations. If I'm
not right, then which two terms differentiate the ACTUAL VISIBILTY AREA
from the TOTAL POSSIBLE VISIBILITY AREA?

Scope is independent of linkage. Definitions or declarations inside a
block have scope that lasts to the end of that block, but block scope
declarations have no linkage. A file scope definition with the static
keyword also has no linkage.

Also, say I have 2 source files main.c and second.c, and there is an
external variable defined at the top of main.c.

I only want to use this variable in 1 function in second.c, can I put
the extern declaration inside the function's braces (will this limit
others in second.c from accessing the variable?) ?

Yes, an external declaration within a block has scope that extends
from the declaration to the end of the block. So no other functions
in that source file will be able to access the object or function by
name.

If the answer above is yes, then that is a better example of what I was
saying above. The scope would be all code in both files, while the
visibility would be all of main.c and just that function in second.c.

No, the scope will be all of the defining file after the definition,
except where it might be hidden by a declaration within a block
reusing the same identifier, if any.

In the second translation unit, the scope is begins at the external
declaration and end at the close of the block, which could be a top
level function block, or even a nested block inside the function.

The scope of an external declaration inside a function is not the
entire source file, it is just the remainder of the enclosing block
after the declaration.

I haven't found enlightenment in any of the books or FAQs I've checked,
so any help would be really appreciated.

The "visibility" you are talking about is exactly what the C language
defines as scope, no more and no less.

 

[Mike Wahler]

[snip]

The other characteristic of objects defined at file scope is linkage.
They either have internal linkage, if the static keyword is part of
the definition, or external linkage by default if the static keyword
is not part of the definition.

static int i; /* internal linkage? */


[snip]

Scope is independent of linkage. Definitions or declarations inside a
block have scope that lasts to the end of that block, but block scope
declarations have no linkage. A file scope definition with the static
keyword also has no linkage.

static int i; /* no linkage? */


-Mike

 

[Ben Pfaff]

Scope is something defined by the C standard. "visibility" is not.

The standard does not specifically define "visibility" but it
does use the term "visible" a fair amount, e.g.:

For each different entity that an identifier designates,
the identifier is visible (i.e., can be used) only within a
region of program text called its scope.
....
Within the inner scope, the identifier designates the entity
declared in the inner scope; the entity declared in the
outer scope is hidden (and not visible) within the inner
scope.

Unless explicitly stated otherwise, where this International
Standard uses the term ``identifier'' to refer to some
entity (as opposed to the syntactic construct), it refers to
the entity in the relevant name space whose declaration is
visible at the point the identifier occurs.
....
If more than one declaration of a particular identifier is
visible at any point in a translation unit, the syntactic
context disambiguates uses that refer to different entities.

 

[Jack Klein]

[snip]

The other characteristic of objects defined at file scope is linkage.
They either have internal linkage, if the static keyword is part of
the definition, or external linkage by default if the static keyword
is not part of the definition.

static int i; /* internal linkage? */

Yes, absolutely.

========
6.2.2 Linkages of identifiers

1 An identifier declared in different scopes or in the same scope more
than once can be made to refer to the same object or function by a
process called linkage. There are three kinds of linkage: external,
internal, and none.

2 In the set of translation units and libraries that constitutes an
entire program, each declaration of a particular identifier with
external linkage denotes the same object or function. Within one
translation unit, each declaration of an identifier with internal
linkage denotes the same object or function. Each declaration of an
identifier with no linkage denotes a unique entity.

3 If the declaration of a file scope identifier for an object or a
function contains the storage class specifier static, the identifier
has internal linkage.
========

Note the meaning of the term in the middle of the paragraph 2, and how
it is produced in paragraph 3.

Consider this translation unit:

int a; /* file scope external linkage */
int a; /* ditto */

extern int b; /* file scope external linkage */
extern int b; /* ditto */

static int c; /* file scope internal linkage */
static int c; /* ditto */

void func(void)
{
int d; /* block scope, no linkage */
int d; /* ditto */

static int e; /* block scope, no linkage */
static int e; /* ditto */
}

And here's the diagnostics produced by one compiler (MSVC++ 6.0):

Compiling...
clc.c
C:\Program Files\Microsoft Visual Studio\MyProjects\clc\clc.c(13) :
error C2086: 'd' : redefinition
C:\Program Files\Microsoft Visual Studio\MyProjects\clc\clc.c(16) :
error C2086: 'e' : redefinition
Error executing cl.exe.

clc.obj - 2 error(s), 0 warning(s)

[snip]

Scope is independent of linkage. Definitions or declarations inside a
block have scope that lasts to the end of that block, but block scope
declarations have no linkage. A file scope definition with the static
keyword also has no linkage.

Got me there, tragic loss between brain and fingers.

 

[Mike Wahler]

[snip]

The other characteristic of objects defined at file scope is linkage.
They either have internal linkage, if the static keyword is part of
the definition, or external linkage by default if the static keyword
is not part of the definition.

static int i; /* internal linkage? */

Yes, absolutely.

That's what I thought.

[snip ISO quote and examples]

Got me there, tragic loss between brain and fingers.

I thought so, but wanted to make sure I wasn't missing
something. (Whenever I'm in doubt about something in
C, you're one of the folks here whose explanations I
give the most weight. But alas you're human too. )

Perhaps I should have phrased my reply differently
(e.g. 'was that a typo?').

I really didn't mean for you to go to all that
trouble posting a quote and examples. Sorry
about that, and thanks.

-Mike

 

[Jack Klein]

[snip]

The other characteristic of objects defined at file scope is linkage.
They either have internal linkage, if the static keyword is part of
the definition, or external linkage by default if the static keyword
is not part of the definition.

static int i; /* internal linkage? */

Yes, absolutely.

That's what I thought.

[snip ISO quote and examples]

Got me there, tragic loss between brain and fingers.

I thought so, but wanted to make sure I wasn't missing
something. (Whenever I'm in doubt about something in
C, you're one of the folks here whose explanations I
give the most weight. But alas you're human too. )

Depends on who you ask!

Perhaps I should have phrased my reply differently
(e.g. 'was that a typo?').

I really didn't mean for you to go to all that
trouble posting a quote and examples. Sorry
about that, and thanks.

-Mike

That's OK, I'm well wound up tonight. I even corrected an error by
Victor Bazarov over on the brand x group, with three quotes from the
brand x standard, and that's almost as rare as catching a Lawrence
Kirby error here, now that Lawrence is back.

 

[Peter Shaggy Haywood]

Groovy hepcat Jack Klein was jivin' on Wed, 09 Feb 2005 23:07:43 -0600
in comp.lang.c.
Re: Is "scope" different from "visibility" ?'s a cool scene! Dig it!

comp.lang.c:

Scope is independent of linkage. Definitions or declarations inside a
block have scope that lasts to the end of that block, but block scope
declarations have no linkage. A file scope definition with the static
keyword also has no linkage.

Uh..., internal linkage, I think, Jack.

-------------------------------------------------------------------
6.2.2 Linkages of identifiers
....
3 If the declaration of a file scope identifier for an object or a
function contains the storageclass specifier static, the identifier
has internal linkage.20)
-------------------------------------------------------------------

--

Dig the even newer still, yet more improved, sig!

http://alphalink.com.au/~phaywood/
"Ain't I'm a dog?" - Ronny Self, Ain't I'm a Dog, written by G. Sherry & W. Walker.
I know it's not "technically correct" English; but since when was rock & roll "technically correct"?

 

[Dave Thompson]

An object or function can only be referenced by name if it is in
scope.

Right. Or perhaps more precisely, if the/a declaration is in scope.

No, there is no such thing as "global scope" in C. Externally defined
objects and functions have file scope. That scope extends from the
point of declaration (note that a definition is also a declaration) to
the end of the translation unit.

True but incomplete; all 'external' (meaning top-level) definitions
_and declarations_ have file scope. That meaning is different from
'external linkage' (which you correctly describe) which can be
confusing. (Ada calls the equivalent 'library level', which is
confusing in a different way.) All definitions are semantically also
declarations, but formally function definitions are not syntactically
declarations while object definitions are, which makes it clumsier to
state rules that are both clear and correct, unfortunately.

The other characteristic of objects defined at file scope is linkage.
They either have internal linkage, if the static keyword is part of
the definition, or external linkage by default if the static keyword
is not part of the definition.

Did you mean (only) object here, or object-or-function=entity? It's
true either way, but needs to be slightly modified: if the function or
file-scope object is declared with 'static' it has internal linkage,
whether or not that declaration is the definition. In most cases it
is, but we have composite cases like:

static int a; /* (forward) declaration and tentative definition */
static void f (void); /* forward declaration */
...
int a = 10; /* definition, overrides t.d., still static=internal */
void f (void) { blah blah blah } /* defined, still internal */
/* even if you actually put 'extern' on the definition,
they still have internal linkage! */

But external linkage does not make an object or function usable by
name from another translation unit. That other translation unit must
have an external declaration of the object or function in scope when
it attempts to use it.

Right. In particular, a nondefining declaration also with external
linkage, which in effect means simply 'extern whatever'.

Scope is independent of linkage. Definitions or declarations inside a
block have scope that lasts to the end of that block, but block scope
declarations have no linkage. A file scope definition with the static
keyword also has no linkage.

No, file-scope with static has internal linkage -- as you already
said. Maybe you meant to say that block-scope declarations with static
have no linkage -- they are always private to that block, unlike
file-scope ones -- while block-scope declarations with extern do have
external linkage like file-scope ones (modulo as above). The "normal"
case for block-scope declarations, automatic (and register) objects,
have no linkage.

(And declarations of types and tags, and enums, never have linkage.
They are compiletime only and don't exist at runtime -- the standard
isn't permitted to actually say so because it would be considered
constraining implementations, but that's the reason.)

Yes, an external declaration within a block has scope that extends
from the declaration to the end of the block. So no other functions
in that source file will be able to access the object or function by
name.

They won't be able to access it using that declaration. There could be
_another_ declaration for the entity in or visible to other functions.

<snip rest>

- David.Thompson1 at worldnet.att.net