Re: OSF build fixed

From: Kurt Roeckx <Q(at)ping(dot)be>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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:39:58
Message-ID: 20030715203958.GA6812@ping.be
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jul 15, 2003 at 04:28:49PM -0400, Tom Lane wrote:
> 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.

BSD 4.3 didn't have an sa_len, while 4.4 did.

in BSD 4.3 sa_family was a short, in 4.4 it was split up in 2
chars.

Note that the RFC has 2 examples, one without sa_len, an other
with sa_len.

Kurt

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2003-07-15 20:47:04 Re: [HACKERS] problems with pg_restore
Previous Message Rod Taylor 2003-07-15 20:30:59 Re: problems with pg_restore