This is the mail archive of the
mailing list for the GCC project.
Re: Results from Intel4s C++ ABI Testsuite
- From: Nick Ing-Simmons <nick at ing-simmons dot net>
- To: mark at codesourcery dot com
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, Goodman Joe <joe dot goodman at intel dot com>, Nathan Sidwell <nathan at codesourcery dot com>, Joe Buck <Joe dot Buck at synopsys dot com>, Andreas Jaeger <aj at suse dot de>, Richard Henderson <rth at redhat dot com>
- Date: Sat, 20 Jul 2002 10:05:01 +0100
- Subject: Re: Results from Intel4s C++ ABI Testsuite
- References: <firstname.lastname@example.org>
- Reply-to: Nick Ing-Simmons <nick at ing-simmons dot net>
Mark Mitchell <email@example.com> writes:
>> It seems that for true C++ binary compatibility all implementers must
>> agree on the type of size_t. Was this overlooked?
>As Richard says, this is pretty much a property of the OS. If "int" and
>"long" are the same, you can interchange the two for binary compatibility
>purposes, but you'll never make your header files work right.
>And, of course, since "size_t" is just a typedef we can't mangle it
>specially, even if we wanted to.
>It is true that if my OS uses "long" and yours uses "int" -- but they
>are the same in all other ways -- then I can't mix and match C++ shared
>objects from our two systems. I can still mix and match C++ shared
>objects from any one of those systems, even if I used different
>compilers to build them.
It seems to me (as a casual reader who does not use C++ much),
that the fact that "type safe linkage" is encoding the "name" of the
type rather than the "type" is sub-optimal. If what was encoded
was "unsigned integer of 32-bits" then the two size_t-s would match.
The "loss" would be that programs that would work on that platform
- even though coded incorrectly - would link.
But catching long vs int confusion is better done before link time.