Re: sockaddr_un.sun_len vs. reality - Mailing list pgsql-hackers

From Tom Lane
Subject Re: sockaddr_un.sun_len vs. reality
Date
Msg-id 2845286.1644852086@sss.pgh.pa.us
Whole thread Raw
In response to Re: sockaddr_un.sun_len vs. reality  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: sockaddr_un.sun_len vs. reality
List pgsql-hackers
Thomas Munro <thomas.munro@gmail.com> writes:
> On Mon, Feb 14, 2022 at 7:19 PM Tom Lane <tgl@sss.pgh.pa.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



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: Merging statistics from children instead of re-sampling everything
Next
From: Robert Haas
Date:
Subject: Re: Mark all GUC variable as PGDLLIMPORT