> -----Original Message-----
> From: Jeroen T. Vermeulen [mailto:jtv@xs4all.nl] 
> Sent: Sunday, April 11, 2004 7:28 AM
> To: Bruce Momjian
> Cc: Dann Corbit; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] 7.5 beta version
> 
> 
> On Mon, Apr 05, 2004 at 09:38:13PM -0400, Bruce Momjian wrote:
> > 
> > I don't think you can mix libs/binaries from different compilers.
> 
> As long as it's plain old C, and the compilers adhere to the 
> platform's ABI standards, why not?  Even if you compile the C 
> code using a C++ compiler, as in this case, any C structs 
> will be PODs and so should be compiled according to the C 
> layout rules.

1.
The C language does not define alignment of structs.

The C language does not specify that an integer shall be the same size
on two different platforms.

The C language does not specify a portable way even to read and write
structs to disk and preserve alignment across platforms.

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.

2.
It is a mistake to use a C++ compiler to compile C code, because the
languages are different.  Stroustrup's statement that good C code tends
to be valid C++ code is not correct.

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:
regc_color.c (225):  struct colordesc *new;
regc_color.c (251):  new = (struct colordesc *) MALLOC(n *
regc_color.c (253):  if (new != NULL)
regc_color.c (254):  memcpy(VS(new), VS(cm->cdspace), cm->ncds *
regc_color.c (258):  new = (struct colordesc *) REALLOC(cm->cd,
regc_color.c (260):  if (new == NULL)
regc_color.c (265):  cm->cd = new;

Mon, 12 Apr 2004 11:55:45 -0700
"Dann Corbit" <DCorbit@connx.com>
Re: 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.


> 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.


> 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.


Jeroen


Mon, 12 Apr 2004 21:24:41 +0200
"Jeroen T. Vermeulen" <jtv@xs4all.nl>
Re: 7.5 beta version