> -----Original Message-----
> From: Jeroen T. Vermeulen [mailto:jtv@xs4all.nl] 
> Sent: Monday, April 12, 2004 12:25 PM
> To: Dann Corbit
> Cc: Bruce Momjian; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] 7.5 beta version
> 
> 
> On Mon, Apr 12, 2004 at 11:55:45AM -0700, Dann Corbit wrote:
>  
> > 1.
> > The C language does not define alignment of structs.
>  
> Platform ABI standards do, though (hence the "as long as it 
> adheres to..." clause in my previous post).  Whether it's in 
> the C language or in the platform's ABI standards is 
> important when writing portable code; it should not matter 
> when compiling an existing product--provided that the 
> platform defines the ABI unambiguously.  The latter is what's 
> in question here.

Where is the definition for a platform ABI?  (Sounds like Application
Binary Interface).
At any rate, there is nothing to force any C compiler to adhere to it.

> > The C language does not specify that an integer shall be 
> the same size 
> > on two different platforms.
> 
> That is not a problem when linking across compilers, only 
> when linking across ABIs.  I would expect that doing so would 
> fail at link time. Besides, as a practical matter, even the 
> 64-bit platforms current today normally specify that int is a 
> 32-bit type so this should not come into play in this case, 
> even when linking e.g. Itanium code to x86 code.
> 
> 
> > The C language does not specify that IEEE arithmetic must 
> be used or 
> > even that a double shall be able to represent a value larger than a 
> > float.
>  
> Again, I doubt this is relevant in this case where the 
> problem is linking across compilers on the same platform, not 
> across platforms.

I do know of important differences in compilers in this regard.  You can
(for instance) have 80 bit floating point on one compiler using double
but it is only 64 bits on another.

The point being that there is no such thing as a binary interface for
alignments or data types that is defined by the C or C++ ANSI/ISO
language standards.  If there is another standard, I would like to hear
about it.


> > Mingw GCC is both a C and a C++ compiler.  Fortunately, the 
> C compiler 
> > is used, because there is no way that the code base would 
> compile as C 
> > code.  A trivial example to show why not is the frequent use of the 
> > C++ keyword 'new' in the code base.  Here is an example:
> 
> With gcc at least, the matter is even simpler than that.  It 
> selects an appropriate front-end (C, C++, ...) based on the 
> names of the source files being compiled.  This may break 
> down at link time however; g++ links to the C++ standard 
> library, which gcc by default doesn't.

Most compilers do something like that.

Here is my puzzlement...
If I compile a PostgreSQL database on some 64 bit machine, I should be
able to access it from a 32 bit machine.  For instance, I can access
DB/2 on our 3090 or Rdb on our Alpha from a 32 bit workstation and I
have no problems of this nature.  Surely it is an issue with PostgreSQL
that has been recognized before.

If I change compilers or if I even completely change architectures it
should not matter.  The interface to the database should be architecture
independent.  Said another way:
I should have no concerns about what sort of architecture the server is
on or what compiler was used.


Mon, 12 Apr 2004 12:35:15 -0700
"Dann Corbit" <DCorbit@connx.com>
Re: 7.5 beta version
On Mon, Apr 12, 2004 at 12:35:15PM -0700, Dann Corbit wrote:
 
> I do know of important differences in compilers in this regard.  You can
> (for instance) have 80 bit floating point on one compiler using double
> but it is only 64 bits on another.
 
But in the case of x86 (among others) that's the in-register
representation, no?  IIRC they are stored to memory as 64-bit doubles at
best.


> The point being that there is no such thing as a binary interface for
> alignments or data types that is defined by the C or C++ ANSI/ISO
> language standards.  If there is another standard, I would like to hear
> about it.
 
That depends on the platform vendor.  Which depending on the platform may
actually be whoever specified the CPU architecture and/or whoever supplied
the OS.  As you say, compilers may deviate from it although in many cases
it would render them useless.

In this particular case, it would most likely be Microsoft as the dominant
{OS,compiler,everything else} vendor.  I *think* (but I'm not sure) that
Microsoft set an ABI even at the C++ level (as Intel also did with the
Itanium, BTW), although it's more common to specify the C level only.

In C++, ABI compatibility is normally protected through a side effect of
name mangling.  By maintaining different name mangling schemes for
different ABI conventions, compiler vendors ensure that object files will
refuse to link to other object files that adhere to different ABIs.

 
> Here is my puzzlement...
> If I compile a PostgreSQL database on some 64 bit machine, I should be
> able to access it from a 32 bit machine.  For instance, I can access
> DB/2 on our 3090 or Rdb on our Alpha from a 32 bit workstation and I
> have no problems of this nature.  Surely it is an issue with PostgreSQL
> that has been recognized before.
 
I would say yes, definitely!  That part is not in question here, only the
linking-across-compilers part.  But see below.


> If I change compilers or if I even completely change architectures it
> should not matter.  The interface to the database should be architecture
> independent.  Said another way:
> I should have no concerns about what sort of architecture the server is
> on or what compiler was used.
 
Unless you use the binary mode of data transfer perhaps; I think that's been
rationalized in 7.4 and is now portable.  No idea what happens if you
convert tables written in an older version (say, 7.3) to 7.5 and then
read them from a wildly different platform than you wrote them from, but
that may be a bit far-fetched.
 

Jeroen


Mon, 12 Apr 2004 22:00:05 +0200
"Jeroen T. Vermeulen" <jtv@xs4all.nl>
Re: 7.5 beta version
On Mon, Apr 12, 2004 at 10:00:05PM +0200, Jeroen T. Vermeulen wrote:
> On Mon, Apr 12, 2004 at 12:35:15PM -0700, Dann Corbit wrote:
>  
> > I do know of important differences in compilers in this regard.  You can
> > (for instance) have 80 bit floating point on one compiler using double
> > but it is only 64 bits on another.
>  
> But in the case of x86 (among others) that's the in-register
> representation, no?  IIRC they are stored to memory as 64-bit doubles at
> best.

You also have "long double"s on some compilers which could be 80 bit.

> In C++, ABI compatibility is normally protected through a side effect of
> name mangling.  By maintaining different name mangling schemes for
> different ABI conventions, compiler vendors ensure that object files will
> refuse to link to other object files that adhere to different ABIs.

We gave up trying to make C++ dlls on windows because of ABI/name
mangling problems, never tried it again though.

The compilers from Microsoft and Borland atleast aren't
compatible.


Kurt


Wed, 14 Apr 2004 00:22:18 +0200
Kurt Roeckx <Q@ping.be>
Re: 7.5 beta version
On Wed, Apr 14, 2004 at 12:22:18AM +0200, Kurt Roeckx wrote:

> > But in the case of x86 (among others) that's the in-register
> > representation, no?  IIRC they are stored to memory as 64-bit doubles at
> > best.
> 
> You also have "long double"s on some compilers which could be 80 bit.
 
Actually, they're a supported feature in both C99 and C++ IIRC.  But I
still suspect they're not *actually* 80 bits, at least not in memory.


> We gave up trying to make C++ dlls on windows because of ABI/name
> mangling problems, never tried it again though.
> 
> The compilers from Microsoft and Borland atleast aren't
> compatible.

But that shows up as link errors, not at runtime, right?


Jeroen


Wed, 14 Apr 2004 11:24:06 +0200
"Jeroen T. Vermeulen" <jtv@xs4all.nl>
Re: 7.5 beta version