Re: sockaddr_un.sun_len vs. reality

Thomas Munro <thomas.munro@gmail.com>

From: Thomas Munro <thomas.munro@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2022-08-23T22:53:52Z
Lists: pgsql-hackers
On Tue, Aug 23, 2022 at 3:43 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Thomas Munro <thomas.munro@gmail.com> writes:
> > I was nerd-sniped by the historical context of this single line of
> > code.  I'd already wondered many times (not just in PostgreSQL)
> > whether and when that became a cargo-cult practice, replicated from
> > other software and older books like Stevens.  I failed to find any
> > sign of an OS that needs it today, or likely even needed it this
> > millennium.  Now I'd like to propose removing it.
>
> Seems worth a try.

Pushed, and build farm looks good.  For the benefit of anyone else
researching this topic, I should add that Stevens in fact said it's OK
to skip this, and if I had opened UNIX Network Programming (3rd ed)
volume I to page 99 I could have saved myself some time: "Even if the
length field is present, we need never set it and need never examine
it, unless we are dealing with routing sockets ...".



Commits

  1. Don't bother to set sockaddr_un.sun_len.

  2. Suppress integer-overflow compiler warning for inconsistent sun_len.