error not caught at link time: should it be?

[nzanella]

Hello,

I have two .cpp files. The first one contains:

Foo *foo;

and in the second one contains:

extern Foo foo;

I am using a modified version of gcc
with Makefiles automatically created.
The strange thing is that the tools
go through the link phase without
detecting the error. Isn't it to
be expected that the error be
caught by the linker???

I feel somewhat surprised that
it didn't catch it. I guess
when the linker looks for
external symbols it doesn't
care about matching their
types (eg. pointer versus value).

Thanks!!!

Neil

 

[Victor Bazarov]

I have two .cpp files. The first one contains:

Foo *foo;

and in the second one contains:

extern Foo foo;

The two 'foo' are different. Essentially you have overloading
of the symbol 'foo' here.

I am using a modified version of gcc
with Makefiles automatically created.

Irrelevant here.

The strange thing is that the tools
go through the link phase without
detecting the error. Isn't it to
be expected that the error be
caught by the linker???

Linking is not part of the language specification.

I feel somewhat surprised that
it didn't catch it. I guess
when the linker looks for
external symbols it doesn't
care about matching their
types (eg. pointer versus value).

Since you didn't post _how_ your 'foo' symbols are used, there is
nothing that can be said about it.

V

 

[Old Wolf]

The two 'foo' are different. Essentially you have overloading
of the symbol 'foo' here.

If the first is at file scope, then it is an ODR violation,
causing undefined behaviour.

A similar situation occurs in the FAQ: one TU contains
char foo[9];
and the other contains
extern char *foo;
which causes undefined behaviour; the latter should have been
extern char foo[];

 

[Victor Bazarov]

If the first is at file scope, then it is an ODR violation,
causing undefined behaviour.

I am still trying to understand (after an evening of thinking about it)
why it would be an ODR violation. The first statement is a declaration
and a *definition* of a pointer, if it's at the namespace level; it has
static storage duration and as such is zero-initialised. So, it's
a null pointer to Foo. Are you saying it's defined elsewhere again?

The second statement is a declaration of a global object of type Foo
defined elsewhere. If there is an ODR violation, it's the second one,
the object, who isn't defined at all. And it only is an error if the
object is _used_, which we haven't been able to see.

A similar situation occurs in the FAQ: one TU contains
char foo[9];
and the other contains
extern char *foo;
which causes undefined behaviour; the latter should have been
extern char foo[];

Again, only if the name is used.

V

 

[msalters]

Victor Bazarov schreef:

Linking is not part of the language specification.

Of course it is. It's the part in which Translation Units are
combined. Like any other part of the standard, there is no
implementation detail mandated, but the phase must be there
in some form. In particular, a _linker_ is not part of the
specs, if the compiler can do it. Same as the preprocessor:
doesn't have to be a standalone tool, but the action must be
performed.

HTH,
Michiel Salters

 

[Old Wolf]

I am still trying to understand (after an evening of thinking about it)
why it would be an ODR violation. The first statement is a declaration
and a *definition* of a pointer, if it's at the namespace level; it has
static storage duration and as such is zero-initialised. So, it's
a null pointer to Foo. Are you saying it's defined elsewhere again?

The second statement is a declaration of a global object of type Foo
defined elsewhere. If there is an ODR violation, it's the second one,
the object, who isn't defined at all. And it only is an error if the
object is _used_, which we haven't been able to see.

Yes, I think ODR violation would be the wrong term.
I can't seem to find relevant text in the Standard that
deals with this issue though.

A similar situation occurs in the FAQ: one TU contains
char foo[9];
and the other contains
extern char *foo;
which causes undefined behaviour; the latter should have been
extern char foo[];

Again, only if the name is used.

OK.