Re: 7.5 beta version

> -----Original Message-----
> From: Jeroen T. Vermeulen [mailto:jtv(at)xs4all(dot)nl]
> Sent: Monday, April 12, 2004 12:25 PM
> To: Dann Corbit
> Cc: Bruce Momjian; pgsql-hackers(at)postgresql(dot)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.