Storage class conflicts and external linkage.

Bill Baxter baxter at garth.UUCP
Mon Aug 20 06:56:35 AEST 1990


The December 1988 ANSI C draft is not real specific about the treatment of the
following situation (assume that foo and foo1 are contained in the same file):

----------------samefile.c-------------------
void
foo ( )
{
	extern void foo1( void );

	.
	.
	.
	foo1();
	.
	.
	.
}

static
foo1( )
{
	.
	.
	.
}
---------------end samefile.c------------------

The function foo declares a function foo1 with external scope and later
references that function.  However, the declaration only has block scope.
Therefore, the function foo should be calling a foo1 which has external
scope.  The foo1 in samefile.c has only static scope. 

I have the following questions:

1.  Does the standard require that the reference to foo1 in foo reference
    a foo1 not contained in samefile.c since the definition of foo1 in
    samefile.c has only static storage class?

2.  In the event that 1 is true, then would the standard require that we
    manufacture a name for one of the functions foo1 (e.g., _Static_foo1)
    to avoid the duplicate name so that the reference to foo1 in foo can
    be made global, and foo1 (more specifically _Static_foo1) can be
    reserved for internal linkage?

In response to these questions I would like specific references to the
Draft standard.

The problem actually arises quite frequently if the declaration of foo1 is
implicit (i.e., the programmer forgot to declare the function foo1 in foo).
I would argue that the implicit declaration only has block scope as well.
This is a major change in semantics over pcc/K&R compilers.  And can be
quite tricky to implement.

The standard states that the compiler is not responsible for generating
a warning when a function declaration has gone out of scope.  However, when
there is a storage class conflict (i.e., extern vs. static) the semantics
have changed.  What is the compiler's responsibility in this situation?

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Bill Baxter       Compiler Group: Advanced Processor Division      (415)852-2333
E-MAIL: {apple|pyramid}!apd!baxter      USPS: 2400 Geng Rd., Palo Alto, CA 94303
_STD_DISC:  INGR has their opinions.  I have mine.  Believe them if conflicting.



More information about the Comp.std.c mailing list