two objects in global scope have the same name

[Mark]

Hello,

consider the following snippet:

struct foo_struct {
int a;
int b;
};

struct foo_struct *foo;
struct foo_struct foo_global;

int foo(int x)
{
....
return 0;
}

int main(void)
{
foo = &foo_global;
...
}

So I have two identifiers but for diferent objects (is it correct to call
function as object?). Is this stricly illegal, or the standard defines such
case as "undefined behavior". What part of the standard describe this?

Thanks.

 

[Stefan Ram]

So I have two identifiers

two declarations, one identifier

but for diferent objects

for »different entities«.

In 6.2.3, ISO/IEC 9899:1999 (E) defines four name spaces.
According to this, that two declarations both declare
a name in the same name space of ordinary identifiers.

 

[Shao Miller]

Hello,

consider the following snippet:

struct foo_struct {
int a;
int b;
};

struct foo_struct *foo;

Above, the file-scope[6.2.1p4] 'foo' is declared as an object with type
'struct foo_struct *'.

struct foo_struct foo_global;

int foo(int x)
{
....
return 0;
}

Above, the file-scope 'foo' is declared as a function taking an 'int'
argument and returning an 'int' value. This is not compatible with the
earlier declaration.

int main(void)
{
foo =&foo_global;
...
}

So I have two identifiers but for diferent objects (is it correct to call
function as object?). Is this stricly illegal, or the standard defines such
case as "undefined behavior". What part of the standard describe this?

6.2.1p4 includes:

"... If an identifier designates two different entities in the same
name space, the scopes might overlap. If so, the scope of one entity
(the inner scope) will be a strict subset of the scope of the other
entity (the outer scope). ..."

This criteria is not met by your file-scope declarations for 'foo'.

 

[Joe Pfeiffer]

A function is not an object.

While technically you are correct, I think you probably understood what
he actually meant.

 

[Mark]

Hi,

You can't define the same name with two different types in the same scope.

It's clear for me now, thanks.

You shouldn't define the same external name with different types in
different
source files, but not all compilers and loaders will catch this.

Could you elaborate on this statement, what can go wrong ? What does the
standard say about such case?

So, if I understand you correctly, this should not happen:

a.h:
extern int x;

a.c:
#include "a.h"
int x;

b.h:
extern long x;

b.c:
#include "b.h"
long x;

So If later I link both object files a.o and b.o into target exeecutable,
and if linker can't catch this, it's possible that compiler may generate
code so that long vale will be assigned to integer object? Please clarify
my doubts.

Thanks in advance !

 

[James Kuyper]

While technically you are correct, I think you probably understood what
he actually meant.

He also explicitly asked whether the term was correct, and pete answered
that question.

 

[James Kuyper]

Hi,



Could you elaborate on this statement, what can go wrong ? What does the
standard say about such case?
6.9p5:
... If an identifier declared with external
linkage is used in an expression (other than as part of the operand of a sizeof operator
whose result is an integer constant), somewhere in the entire program there shall be
exactly one external definition for the identifier; otherwise, there shall be no more than
one.

Those "shall"s occur outside of a constraint section. Code which
violates them therefore has undefined behavior (4p2). That means that
the C standard imposes no requirements on what the implementation does
with your code. In principle, that means that just about anything can
happen.

In practice, if the linker even accepts such code, one common
possibility is that both definitions will share overlapping pieces of
memory, as if they were in a union with each other. Another possibility
is that they are stored in completely different pieces of memory. A
third possibility is that they are assigned to a piece of memory that's
only big enough to store the smaller type, and that any attempt to read
or write using the definition with the larger type will attempt to
access memory allocated for some other use, generally with catastrophic
consequences.

So, if I understand you correctly, this should not happen:

More precisely, this should not be done. It can quite easily happen.

a.h:
extern int x;

a.c:
#include "a.h"
int x;

b.h:
extern long x;

b.c:
#include "b.h"
long x;

So If later I link both object files a.o and b.o into target exeecutable,
and if linker can't catch this, it's possible that compiler may generate
code so that long vale will be assigned to integer object?

That's among the least likely of the possibilities, but it is also
technically possible.

 

[Mark]

Hello
Thanks a lot for comments.

6.9p5:

Those "shall"s occur outside of a constraint section. Code which
violates them therefore has undefined behavior (4p2). That means that
the C standard imposes no requirements on what the implementation does
with your code. In principle, that means that just about anything can
happen.

Consider this snippet:

a.h:
extern int x;

a.c:
#include "a.h"
int x;

b.h:
extern long x(void);

b.c:
#include "b.h"
long x(void)
{
return 1;
}

How does the Standard interpret this case? I think that 6.9.1p6 applies to
this case, and results in underfined behavior as well ?

Thanks.

 

[James Kuyper]

Hello
Thanks a lot for comments.



Consider this snippet:

a.h:
extern int x;

a.c:
#include "a.h"
int x;

b.h:
extern long x(void);

b.c:
#include "b.h"
long x(void)
{
return 1;
}

How does the Standard interpret this case? I think that 6.9.1p6 applies to
this case, and results in underfined behavior as well ?

?
6.9.1p6 is about function declarations with identifier lists, also known
as K&R style declarations. Example:

oldfunc(a, b)
char a;
double b;
{
return a+b;
}

They were quickly abandoned shortly after the concept of function
prototypes was introduced. Nowadays they are generally found only in
legacy code and obfuscated C contests; there are none in your example.

The clause I cited was 6.9p5. It defines the term "external definition",
to include definitions of either functions or objects. The "shall"
statements in that clause are about "external definitions". Note,
however, that your code does not yet meet the conditions needed to have
undefined behavior. You have not actually created a single program
containing both translation units. Even if you did, that program does
not yet contain any code which actually uses 'x'. Until you add such
code, the first "shall" in 6.9p5 has not yet been violated.