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
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 |