Re: sockaddr_un.sun_len vs. reality

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: sockaddr_un.sun_len vs. reality
Дата
Msg-id 2845286.1644852086@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: sockaddr_un.sun_len vs. reality  (Thomas Munro <thomas.munro@gmail.com>)
Ответы Re: sockaddr_un.sun_len vs. reality  (Thomas Munro <thomas.munro@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: Merging statistics from children instead of re-sampling everything
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Mark all GUC variable as PGDLLIMPORT