why this program is Crashing

[Pallav singh]

file1.c
int arr[100];


file2.c
extern int * arr;
int main( )
{
printf(“ value at arr[20] is = %d \n”,arr[20] );
return 0;
}

 

[Juha Nieminen]

file1.c
int arr[100];


file2.c
extern int * arr;

ODR violation. file1.c says that arr is an array of 100 ints, and
file2.c says that it's a pointer to int. They are not the same type.

Shouldn't that cause a linker error?

 

[Alf P. Steinbach]

* Pete Becker:

Pallav singh wrote:
file1.c
int arr[100];


file2.c
extern int * arr;
ODR violation. file1.c says that arr is an array of 100 ints, and
file2.c says that it's a pointer to int. They are not the same type.

Shouldn't that cause a linker error?

ODR violations do not require diagnostics. Most compilation systems
don't check data types across modules.

This surprised me (the OP showed that he compiled as C; I thought compilation as
C++, with presumably mangled names, would yield a linker error, but no).


- Alf

 

[James Kanze]

* Pete Becker:

Pete Becker wrote:
Pallav singh wrote:
file1.c
int arr[100];
file2.c
extern int * arr;
ODR violation. file1.c says that arr is an array of 100 ints, and
file2.c says that it's a pointer to int. They are not the same type.
Shouldn't that cause a linker error?

ODR violations do not require diagnostics. Most compilation systems
don't check data types across modules.

This surprised me (the OP showed that he compiled as C; I
thought compilation as C++, with presumably mangled names,
would yield a linker error, but no).

It's stupid, but most C++ compilers only mangle function names.
Some sort of "extended" naming is necessary to support
overloaded functions. Since you can't overload data, it's not
strictly necessary for data. But it would certainly be an
advantage for the user. For that matter: why not mangle in an
MD5 hash of the definition of things that allow or require
multiple definitions, like classes, templates and inline
functions. A simple and easy way of catching one of the more
frequent causes of undefined behavior, maybe not 100% of the
time, but something like 99.9999%, which is still better than
nothing.

 

[Paul Brettschneider]

* Pete Becker:

Juha Nieminen wrote:
Pete Becker wrote:
Pallav singh wrote:
file1.c
int arr[100];
file2.c
extern int * arr;
ODR violation. file1.c says that arr is an array of 100 ints, and
file2.c says that it's a pointer to int. They are not the same type.
Shouldn't that cause a linker error?
ODR violations do not require diagnostics. Most compilation systems
don't check data types across modules.

This surprised me (the OP showed that he compiled as C; I
thought compilation as C++, with presumably mangled names,
would yield a linker error, but no).

It's stupid, but most C++ compilers only mangle function names.
Some sort of "extended" naming is necessary to support
overloaded functions. Since you can't overload data, it's not
strictly necessary for data.

Yes, strange indeed. OTOH, name mangling would defacto enable overloading of
data, even though the language doesn't allow it:

File 1:

double v = 3.141592;

File 2:

int v = 12345;

File 3:

int f1()
{
extern int v;
return v;
}

double f2()
{
extern double v;
return v;
}

Scary.

But it would certainly be an
advantage for the user. For that matter: why not mangle in an
MD5 hash of the definition of things that allow or require
multiple definitions, like classes, templates and inline
functions.

But why stop there and not just provide type information in the object
files. The linker (dynamic or static) would then be responsible for only
linking variables with compatible types. The infrastructure is there
(debuggers), just make type information mandatory.

 

[James Kanze]

* Pete Becker:
Juha Nieminen wrote:
Pete Becker wrote:
Pallav singh wrote:
file1.c
int arr[100];
file2.c
extern int * arr;
ODR violation. file1.c says that arr is an array of 100
ints, and file2.c says that it's a pointer to int. They
are not the same type.
Shouldn't that cause a linker error?
ODR violations do not require diagnostics. Most
compilation systems don't check data types across
modules.
This surprised me (the OP showed that he compiled as C; I
thought compilation as C++, with presumably mangled names,
would yield a linker error, but no).

It's stupid, but most C++ compilers only mangle function
names. Some sort of "extended" naming is necessary to
support overloaded functions. Since you can't overload
data, it's not strictly necessary for data.

Yes, strange indeed. OTOH, name mangling would defacto enable
overloading of data, even though the language doesn't allow
it:

File 1:

double v = 3.141592;

File 2:

int v = 12345;

File 3:

int f1()
{
extern int v;
return v;
}

double f2()
{
extern double v;
return v;
}

Scary.

Good point. That may be why earlier implementations (which used
linkers designed for C) didn't do it.

There's nothing, of course, to prevent the linker from
complaining about a double definition when it sees v__d and
v__i, or whatever---when it recognizes that the two mangled
names derived from the same symbol in source, and refer to data.
But then, there's nothing to prevent using an intelligent
linker, which doesn't use mangling at all, but rather is passed
the complete type information (in some structured form). (This
would, of course, require some extensions to the object format.)

But why stop there and not just provide type information in
the object files. The linker (dynamic or static) would then be
responsible for only linking variables with compatible types.
The infrastructure is there (debuggers), just make type
information mandatory.

Exactly. My suggestion was just a simple idea which could be
quickly implemented (less than one man day, for someone who is
already familiar with the compiler sources), using existing
linkers. (Of course, the error message wouldn't be all that
clear. But the compiler implementer could document what certain
"undefined external" could mean. And I'd rather have to figure
out an obtuse error message when linking, than a strange core
dump when running.)