> The real issue is that since the sun_len member is unique to 4.4BSD-
> based systems, very little source code uses it.

Was it in Net/2?  I forget.

There are more "4.4BSD-based" systems than one would think, since lots
of people take the stock berkeley networking code and graft it into
their systems.  For instance, Digital UNIX _does_ have a sun_len
member in its sockaddr_un and a SUN_LEN macro, and it's not really
4.4BSD-based...


> Also, third-party code (and even some code in our tree) ignores
> sun_len.  Since very little userland code bothers to fill it in, it
> cannot be assumed to be valid.

I'm not sure that this is true, for either this comment or the
endianness comment.  The kernel contains code to deal with the changes
in the sockaddr* structures and the family/length problems that they
cause.


> The only reason netstat(8) ever worked
> at all is that code inside the kernel appends a null to sun_path.

And, given that code's methodology, it seems that the NUL (not a
"null") isn't supposed to be included in the length.  However, that's
not entirely conclusive.


> reason you see garbage when you run 'netstat | cat -v' is that (as of
> now) the null is stuffed into the wrong location in sun_path.

Really?  I'm not entirely sure i believe this, and would like some
"proof" that this is what's actually happening.


> I'm still unsure what the best solution is.

Neither am I.  However, I don't think that the right solution is to
change this interface in this subtle way, especially since there are a
bunch of other OSes which do it the way it was done in 4.4.


> I think cgd was within
> his rights to back out my change to <sys/un.h>,

I know I was.  Only a portion of the patch in the PR was checked in,
with no explanation either in the PR (which was left 'open', btw) or
in the commit message as to why that was done.  Additionally, I got
core's approval to back it out before I did.


> but either SUN_LEN
> must be modified, or (more likely) the 'including null' part of that
> comment has to go.  I will continue to look into this.

Sounds like a good plan.


cgd