Re: why this program is Crashing
On Jul 15, 8:48 pm, Paul Brettschneider <paul.brettschnei...@yahoo.fr>
wrote:
James Kanze wrote:
On Jul 14, 3:59 pm, "Alf P. Steinbach" <al...@start.no> wrote:
* 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 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.
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.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34