This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Results from Intel4s C++ ABI Testsuite
- From: Gabriel Dos Reis <gdr at codesourcery dot com>
- To: Joe Buck <Joe dot Buck at synopsys dot com>
- Cc: rth at redhat dot com (Richard Henderson), nathan at codesourcery dot com (Nathan Sidwell), aj at suse dot de (Andreas Jaeger), gcc at gcc dot gnu dot org, joe dot goodman at intel dot com (Goodman Joe)
- Date: 10 Jul 2002 22:51:43 +0200
- Subject: Re: Results from Intel4s C++ ABI Testsuite
- Organization: CodeSourcery, LLC
- References: <200207102041.NAA27631@atrus.synopsys.com>
Joe Buck <Joe.Buck@synopsys.com> writes:
| On Sat, Jul 06, 2002 at 08:11:36PM +0100, Nathan Sidwell wrote:
| > > I don't have a C std in front of me, but IIRC size_t
| > > is the first of 'unsigned int', 'unsigned long', 'unsigned long long'
| > > that can hold an object's size. So, on an ILP32 machine, it will be
| > > 'unsigned int' and operator new (size_t) will be _Znwj.
|
| Richard H writes:
| > Nope. C standard only says it will be unsigned, nothing more.
| >
| > About half of the ILP32 OSs use "unsigned int", and the other
| > half use "unsigned long". You can do nothing but agree with
| > whatever the person who wrote the system headers decided.
|
| It seems that for true C++ binary compatibility all implementers must
| agree on the type of size_t. Was this overlooked?
I can't say, that was overlooked. I'd just say that is part of things
that are not portable across implementations, just like
std::string::size_type.
-- Gaby