Re: sockaddr_un.sun_len vs. reality

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: sockaddr_un.sun_len vs. reality
Date: 2022-02-14 15:21:26
Message-ID: 2845286.1644852086@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> On Mon, Feb 14, 2022 at 7:19 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I'm leaning to adding a compile-time clamp on the value,
>> that is
>>
>> unp->sun_len = Min(sizeof(struct sockaddr_un),
>> (1 << (sizeof(unp->sun_len) * 8)) - 1);

> Any system that has sun_len, and has expanded sun_path so that the
> struct size doesn't fit in sun_len, must surely be ignoring sun_len
> but retaining it for binary compatibility. Otherwise there would be
> no way to use the extra bytes of sun_path! It's tempting to suggest
> setting sun_len to zero in this case...

Yeah, I thought about doing that or just skipping the assignment
altogether. However, we'd need just as much code, because the
change would have to be conditional on more or less this same
computation as to whether sizeof(struct sockaddr_un) fits into
the field.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2022-02-14 15:29:53 Re: Mark all GUC variable as PGDLLIMPORT
Previous Message Tomas Vondra 2022-02-14 15:16:19 Re: Merging statistics from children instead of re-sampling everything