 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
glongword
Guest
|
 Posted: Thu Apr 22, 2004 12:12 am Post subject: typesafe linkage |
 |
|
I saw this curious behavior of C++ recently. It compiles and runs with
g++ and VS.NET.
Let's say we have two files - main.cpp and func.cpp - as below.
//----------------------------
//File main.cpp
class A
{
int a;
public:
A(int i = 0) : a(i) {}
};
void func(A& a);
int main()
{
int i;
A a;
func(a);
}
//File func.cpp where func is defined
class A // redefining A
{
public:
int b;
int c;
};
void func(A& a)
{
// some code which modifies a.b and a.c explicitly
}
//----------------------------
This compiles and runs clobbering the private data and the local
variables of main() (I did this on x86) by simply modifying the member
data of A in func.cpp. I am not sure if this is the intended language
behavior. Shouldn't class names be handled more intelligently across
files?
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
 |
llewelly
Guest
|
| Posted: Thu Apr 22, 2004 3:19 pm Post subject: Re: typesafe linkage |
|
|
[email]glongword (AT) yahoo (DOT) com[/email] (glongword) writes:
[snip]
| Quote: | class A
{
int a;
public:
A(int i = 0) : a(i) {}
};
void func(A& a);
int main()
{
int i;
A a;
func(a);
}
//File func.cpp where func is defined
class A // redefining A
{
public:
int b;
int c;
};
[snip] |
Here you have two different things which are both called class
A. This is an ODR violation. The program is ill-formed, and no
diagnostic is required.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Jack Klein
Guest
|
| Posted: Thu Apr 22, 2004 3:20 pm Post subject: Re: typesafe linkage |
|
|
On 21 Apr 2004 20:12:08 -0400, [email]glongword (AT) yahoo (DOT) com[/email] (glongword) wrote
in comp.lang.c++.moderated:
| Quote: | I saw this curious behavior of C++ recently. It compiles and runs with
g++ and VS.NET.
Let's say we have two files - main.cpp and func.cpp - as below.
//----------------------------
//File main.cpp
class A
{
int a;
public:
A(int i = 0) : a(i) {}
};
void func(A& a);
int main()
{
int i;
A a;
func(a);
}
//File func.cpp where func is defined
class A // redefining A
{
public:
int b;
int c;
};
void func(A& a)
{
// some code which modifies a.b and a.c explicitly
}
//----------------------------
This compiles and runs clobbering the private data and the local
variables of main() (I did this on x86) by simply modifying the member
data of A in func.cpp. I am not sure if this is the intended language
behavior. Shouldn't class names be handled more intelligently across
files?
|
You broke the very fundamental C++ "one definition rule", and the
result is undefined behavior. That is the way C++ is defined. If you
feel that the standard should be changed, the group that you want to
discuss the idea is comp:std:c++, which is about the past, present and
future of the standard.
--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Michiel Salters
Guest
|
| Posted: Fri Apr 23, 2004 12:10 am Post subject: Re: typesafe linkage |
|
|
[email]glongword (AT) yahoo (DOT) com[/email] (glongword) wrote in message news:<7e3a6f40.0404210746.54da0d60 (AT) posting (DOT) google.com>...
| Quote: | I saw this curious behavior of C++ recently. It compiles
and runs with g++ and VS.NET.
Let's say we have two files - main.cpp and func.cpp - as below.
//----------------------------
//File main.cpp
class A
{
int a;
public:
A(int i = 0) : a(i) {}
};
//File func.cpp where func is defined
class A // redefining A
{
public:
int b;
int c;
};
|
This violates the One Definition Rule. No diagnostic is required, but the
behavior is undefined. By definition, all compilers are right when they
compile this code.
Regards,
Michiel Salters
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
kanze@gabi-soft.fr
Guest
|
| Posted: Fri Apr 23, 2004 10:38 am Post subject: Re: typesafe linkage |
|
|
[email]glongword (AT) yahoo (DOT) com[/email] (glongword) wrote in message
news:<7e3a6f40.0404210746.54da0d60 (AT) posting (DOT) google.com>...
| Quote: | I saw this curious behavior of C++ recently. It compiles and runs with
g++ and VS.NET.
Let's say we have two files - main.cpp and func.cpp - as below.
//----------------------------
//File main.cpp
class A
{
int a;
public:
A(int i = 0) : a(i) {}
};
void func(A& a);
int main()
{
int i;
A a;
func(a);
}
//File func.cpp where func is defined
class A // redefining A
{
public:
int b;
int c;
};
void func(A& a)
{
// some code which modifies a.b and a.c explicitly
}
//----------------------------
This compiles and runs clobbering the private data and the local
variables of main() (I did this on x86) by simply modifying the member
data of A in func.cpp. I am not sure if this is the intended language
behavior. Shouldn't class names be handled more intelligently across
files?
|
Technically, this is undefined behavior. The language makes no
requirements as to what may happen. It was defined so (rather than
requiring an error message) in order that C++ be compilable using
conventional compile/link technologies at the time.
In practice, I have often wondered why no compiler does issue an error
(or at least a warning) here. It shouldn't be too hard to put an MD5
hash of all such class definitions in the object files, and have the
linker issue the error whenever the MD5 hash isn't identical. This
isn't perfect -- there's a one in a couple of billion chance that two
different versions will have the same hash, and of course, it totally
ignores name bindings. But it's better than nothing.
Typically, the problem doesn't show itself in this way, of course. You
put the class definitions in a header file, and include it, so all
modules see the same definition. Until you modify the definition, and
for one reason or another, some of the object files don't get
recompiled. Which is a frequent enough problem to make it worth
solving.
--
James Kanze GABI Software mailto:kanze (AT) gabi-soft (DOT) fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Antoun Kanawati
Guest
|
| Posted: Sat Apr 24, 2004 12:19 am Post subject: Re: typesafe linkage |
|
|
[email]kanze (AT) gabi-soft (DOT) fr[/email] wrote:
| Quote: | In practice, I have often wondered why no compiler does issue an error
(or at least a warning) here. It shouldn't be too hard to put an MD5
hash of all such class definitions in the object files, and have the
linker issue the error whenever the MD5 hash isn't identical. This
isn't perfect -- there's a one in a couple of billion chance that two
different versions will have the same hash, and of course, it totally
ignores name bindings. But it's better than nothing.
|
About 15 years ago, I was working with C on VOS (Stratus computers), and
their linker did complain when there were argument or return value
mismatches on functions, and at some other mismatches (can't recall
all the features).
That is the only linker I've met, so far, that did something this
interesting.
It would be interesting to retro-fit such capabilities onto existing
compilers. We have a multitude of tools for extracting program entities
from source (e.g.: Doxygen and similar tools), and tools to look into
object files and symbol tables (e.g.: nm, c++filt).
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
kanze@gabi-soft.fr
Guest
|
| Posted: Mon Apr 26, 2004 2:23 pm Post subject: Re: typesafe linkage |
|
|
Antoun Kanawati <antounk (AT) comcast (DOT) net> wrote
| Quote: | kanze (AT) gabi-soft (DOT) fr wrote:
In practice, I have often wondered why no compiler does issue an
error (or at least a warning) here. It shouldn't be too hard to put
an MD5 hash of all such class definitions in the object files, and
have the linker issue the error whenever the MD5 hash isn't
identical. This isn't perfect -- there's a one in a couple of
billion chance that two different versions will have the same hash,
and of course, it totally ignores name bindings. But it's better
than nothing.
About 15 years ago, I was working with C on VOS (Stratus computers),
and their linker did complain when there were argument or return value
mismatches on functions, and at some other mismatches (can't recall
all the features).
|
About 25 years ago, the Intel linker for the 8086 did this, at least
partially, for functions defined in PL/M. The Intel 8086 linker format
supported it.
| Quote: | That is the only linker I've met, so far, that did something this
interesting.
|
N'est-ce pas? A far more intelligent solution than name mangling.
| Quote: | It would be interesting to retro-fit such capabilities onto existing
compilers. We have a multitude of tools for extracting program
entities from source (e.g.: Doxygen and similar tools), and tools to
look into object files and symbol tables (e.g.: nm, c++filt).
|
I believe that at one time, Rational (with their Apex compilers) was
considering something along these lines. In their case, the potential
would have been tremendous -- integration of the symbol tables in the
compiler, linker and in Rational Rose. I was really looking forward to
it, but I don't think it ever came about.
Note that the problem in C++ is more than just function parameters. You
want to be sure that everyone agrees on the definition of all of the
classes, for example.
--
James Kanze GABI Software mailto:kanze (AT) gabi-soft (DOT) fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Antoun Kanawati
Guest
|
| Posted: Wed Apr 28, 2004 12:37 am Post subject: Re: typesafe linkage |
|
|
[email]kanze (AT) gabi-soft (DOT) fr[/email] wrote:
| Quote: | Antoun Kanawati <antounk (AT) comcast (DOT) net> wrote in message
...
It would be interesting to retro-fit such capabilities onto existing
compilers. We have a multitude of tools for extracting program
entities from source (e.g.: Doxygen and similar tools), and tools to
look into object files and symbol tables (e.g.: nm, c++filt).
...
Note that the problem in C++ is more than just function parameters. You
want to be sure that everyone agrees on the definition of all of the
classes, for example.
|
I was thinking that with Doxygen-like tools, it is possible to
extract data like class/struct member names, types and sequence,
function return types, and other data not usually available in
the common object file.
I also recall something that was called CIA++, a derivative of
an earlier product called CIA (C Information Abstractor). If my
memory serves right, these programs compiled all kinds of data
from source into a database, and were used to build tools for
all sorts of program analysis (impact analysis, where is X used?,
etc...) This was done at AT&T, a long time ago, and wasn't free.
I wonder if any of that stuff remains anywhere.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
kanze@gabi-soft.fr
Guest
|
| Posted: Wed Apr 28, 2004 8:00 pm Post subject: Re: typesafe linkage |
|
|
Antoun Kanawati <antounk (AT) comcast (DOT) net> wrote
| Quote: | kanze (AT) gabi-soft (DOT) fr wrote:
Antoun Kanawati <antounk (AT) comcast (DOT) net> wrote in message
...
It would be interesting to retro-fit such capabilities onto existing
compilers. We have a multitude of tools for extracting program
entities from source (e.g.: Doxygen and similar tools), and tools to
look into object files and symbol tables (e.g.: nm, c++filt).
...
Note that the problem in C++ is more than just function parameters.
You want to be sure that everyone agrees on the definition of all of
the classes, for example.
I was thinking that with Doxygen-like tools, it is possible to extract
data like class/struct member names, types and sequence, function
return types, and other data not usually available in the common
object file.
|
It's not quite the same thing. Doxygen doesn't extract the order, for
example, nor does it look into inline functions. It would probably be
fairly simple to add the first; the second would be a bit harder.
| Quote: | I also recall something that was called CIA++, a derivative of an
earlier product called CIA (C Information Abstractor). If my memory
serves right, these programs compiled all kinds of data from source
into a database, and were used to build tools for all sorts of program
analysis (impact analysis, where is X used?, etc...) This was done at
AT&T, a long time ago, and wasn't free.
|
I believe that at one time, Rational was looking into using a common
data base for its compilers and Rose.
| Quote: | I wonder if any of that stuff remains anywhere.
|
Well, Doxygen is definitly alive and kicking. Having already converted
much of my documentation into its format, I hope it stays that way.
--
James Kanze GABI Software mailto:kanze (AT) gabi-soft (DOT) fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Tom Tanner
Guest
|
| Posted: Fri Apr 30, 2004 9:08 am Post subject: Re: typesafe linkage |
|
|
[email]kanze (AT) gabi-soft (DOT) fr[/email] wrote in message news:<d6652001.0404220509.46dddc79 (AT) posting (DOT) google.com>...
| Quote: | glongword (AT) yahoo (DOT) com (glongword) wrote in message
news:<7e3a6f40.0404210746.54da0d60 (AT) posting (DOT) google.com>...
snip example of class A being redefined
Technically, this is undefined behavior. The language makes no
requirements as to what may happen. It was defined so (rather than
requiring an error message) in order that C++ be compilable using
conventional compile/link technologies at the time.
In practice, I have often wondered why no compiler does issue an error
(or at least a warning) here. It shouldn't be too hard to put an MD5
hash of all such class definitions in the object files, and have the
linker issue the error whenever the MD5 hash isn't identical. This
isn't perfect -- there's a one in a couple of billion chance that two
different versions will have the same hash, and of course, it totally
ignores name bindings. But it's better than nothing.
Wouldn't a simpler solution be to give a warning for a function with |
external linkage which has a parameter or return type which isn't
defined in an included file (not so reliable of course, but doesn't
require any changes to the linker).
| Quote: | Typically, the problem doesn't show itself in this way, of course. You
put the class definitions in a header file, and include it, so all
modules see the same definition. Until you modify the definition, and
for one reason or another, some of the object files don't get
recompiled. Which is a frequent enough problem to make it worth
solving.
Isn't that what make does for you? |
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
kanze@gabi-soft.fr
Guest
|
| Posted: Mon May 03, 2004 9:47 am Post subject: Re: typesafe linkage |
|
|
[email]ttanner2 (AT) bloomberg (DOT) net[/email] (Tom Tanner) wrote in message
news:<22f7de4e.0404290802.4b328589 (AT) posting (DOT) google.com>...
| Quote: | kanze (AT) gabi-soft (DOT) fr wrote in message
news:<d6652001.0404220509.46dddc79 (AT) posting (DOT) google.com>...
[email]glongword (AT) yahoo (DOT) com[/email] (glongword) wrote in message
news:<7e3a6f40.0404210746.54da0d60 (AT) posting (DOT) google.com>...
snip example of class A being redefined
Technically, this is undefined behavior. The language makes no
requirements as to what may happen. It was defined so (rather than
requiring an error message) in order that C++ be compilable using
conventional compile/link technologies at the time.
In practice, I have often wondered why no compiler does issue an
error (or at least a warning) here. It shouldn't be too hard to put
an MD5 hash of all such class definitions in the object files, and
have the linker issue the error whenever the MD5 hash isn't
identical. This isn't perfect -- there's a one in a couple of
billion chance that two different versions will have the same hash,
and of course, it totally ignores name bindings. But it's better
than nothing.
Wouldn't a simpler solution be to give a warning for a function with
external linkage which has a parameter or return type which isn't
defined in an included file (not so reliable of course, but doesn't
require any changes to the linker).
|
How is that a solution? And to what? (The problem in question was
violations of the ODR, typically due to changes in an include file, and
some of the object files not getting recompiled.)
| Quote: | Typically, the problem doesn't show itself in this way, of course.
You put the class definitions in a header file, and include it, so
all modules see the same definition. Until you modify the
definition, and for one reason or another, some of the object files
don't get recompiled. Which is a frequent enough problem to make it
worth solving.
Isn't that what make does for you?
|
On really small projects, where there is just one person. On larger
projects, it depends on how the source code control works -- there can
be a significant difference between the last modified time of a file
(what make looks at) and the moment the file becomes visible to you. Or
you might pick up different versions of the library and the header
files.
Really good source code control systems, such as ClearCase, generally
provide their own make, which knows what was and was not visible, and
ensures coherence. But that isn't true for all source code control
systems, and there is also the problem of portability of the makefile,
if you have to export a package with sources and the makefile for use by
others.
--
James Kanze GABI Software mailto:kanze (AT) gabi-soft (DOT) fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
