From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Kurt Roeckx <Q(at)ping(dot)be> |
Cc: | Philip Yarra <philip(at)utiba(dot)com>, Joe Conway <mail(at)joeconway(dot)com>, pgsql-hackers(at)postgresql(dot)org, Samuel A Horwitz <horwitz(at)argoscomp(dot)com> |
Subject: | Re: OSF build fixed |
Date: | 2003-07-15 20:28:49 |
Message-ID: | 8515.1058300929@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Kurt Roeckx <Q(at)ping(dot)be> writes:
> On Tue, Jul 15, 2003 at 01:56:55PM -0400, Tom Lane wrote:
>> Applied (along with some further hacking to make the struct padding
>> logic more robust).
> I'm not sure what you did exactly, or why you think it's better.
> But it seems you removed the "6 byte pad", between the
> ss_family and the __ss_align, and I have no idea why.
If the pad is needed, it'll be there. Making it explicit doesn't
buy anything.
> Note that I didn't just make that structure up, other people did.
> It's for instance like that in the RFC and in SUS v3.
I wouldn't have touched it if the code actually worked, but it does not
work as intended once you stick in the #ifdef SALEN thingy. The padding
computation was not accounting for that. To make it work correctly
we'd have had to add an additional explicit pad field ... which, if
sa_family_t happened to be "char" and not "short", would be a
zero-element array, resulting in a compile failure.
As I see it, there are two things this struct declaration is trying to
do: make sure the struct is of total size 128 bytes, and make sure it
has alignment as good as the worst-case alignment requirement that the
platform has for integer datatypes. (We assume that sockaddr is
unlikely to contain any float fields ;-), so we need not worry about
the prospect that floats might have stronger alignment requirement than
int64.) The revised code accomplishes both those things.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Rod Taylor | 2003-07-15 20:30:59 | Re: problems with pg_restore |
Previous Message | Kuhn, Dylan K (4520500D) | 2003-07-15 20:26:37 | Re: problems with pg_restore |