From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Greg Stark <gsstark(at)mit(dot)edu> |
Cc: | "Magnus Hagander" <mha(at)sollentuna(dot)net>, "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Charles F(dot) I(dot) Savage" <cfis(at)interserv(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Building Windows Server Extensions Using VC++ 2005 |
Date: | 2006-03-04 17:29:40 |
Message-ID: | 21766.1141493380@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greg Stark <gsstark(at)mit(dot)edu> writes:
> Well that sort of stuff is supposed to be covered by the ABI. Consider that if
> it didn't then you wouldn't be able to use any of the standard libraries
> without recompiling them for each compiler since a number of standard library
> APIs depend on structs like timeval or stat.
Maybe. My experience with these sorts of problems is fairly old (hard
lessons from libjpeg development in the mid-90s), but what I learned at
the time is that all the standard Unix library interfaces are carefully
designed to be fairly impervious to struct padding rules (eg, all the
fields are "int", or at least all the same size), and so you can get
apparent interoperability between compilers that don't agree on these
rules. Meanwhile, Microsoft, who never met a feature they didn't like,
invented a foot-gun called #pragma pack, and then had to fix all their
headers to nail down the pack setting. That in turn masks compatibility
issues on that platform, but only if you're willing to #pragma-ify all
of your own headers too.
In short, I don't trust anybody on this issue. I have the scars to
remind me why not.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Charlie Savage | 2006-03-04 17:35:59 | Re: Building Windows Server Extensions Using VC++ 2005 |
Previous Message | Tom Lane | 2006-03-04 17:19:39 | Re: problem with large maintenance_work_mem settings and |