Re: OSF build fixed

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 21:14:52
Message-ID: 8862.1058303692@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:
> Note that the RFC has 2 examples, one without sa_len, an other
> with sa_len.

If you're talking about RFC 3493, the example with ss_len is flat wrong,
since it fails to allow for the (strong) possibility that there will be
a pad byte between ss_len and ss_family. This will typically result in
making the struct alignof(int64) bigger than intended, since __ss_pad1
will be one byte too big, forcing __ss_align up to the next allowable
alignment boundary. This is no doubt harmless, but there is little
point in having such a complicated declaration if it fails to achieve
its intended goal of exactly controlling the struct's size and
alignment.

BTW, where are we getting the "SALEN" macro from, and how are we sure
that it tells the truth about whether the platform expects an ss_len
field?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kurt Roeckx 2003-07-15 21:20:14 Re: OSF build fixed
Previous Message Alvaro Herrera 2003-07-15 20:47:04 Re: [HACKERS] problems with pg_restore