> Looking at PR lib/34744, I was not sure if we expect userland to set
> sun_len correctly.  A quick grep through our tree shows about 10 out
> of about 20 source files doing it, the others seem to leave sun_len
> as zero.

> The kernel cares about sun_len at very few places, and I fail to see
> the big picture. Since apparently the userland parts that do not set
> sun_len work just fine, I guess we could replace the few kernel
> usages of sun_len with SUN_LEN()?

Since sun_len is the sockaddr_un pun of sockaddr.sa_len, I would very
much prefer to make sure everything sets sun_len correctly, and make
the kernel use it properly.

In particular, that's the only way I can see to make AF_LOCAL sockets
with path names longer than 103 octets work properly.  Most of my code
that uses AF_LOCAL with non-null names malloc()s based on an expression
rather like SUN_LEN, rather than allocating a struct sockaddr_un and
trusting the path name to fit.  It is also careful to set sun_len
correctly.

Really, the AF_LOCAL sockaddr interface needs to be better-specified.
Its interface contract is currently left unspecified in many important
respects, such as these....

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B