Bug#187391: PortingIssues sockaddr_un

[Ognyan Kulev]

(ops, I forgot to Cc: bug-hurd too.)

This discussion is about
http://hurd.gnufans.org/bin/view/Distrib/PortingIssues#Uncompliant_use_of_sockaddr_un_t
We need an agreement about what should be in this page.

Robert Millan wrote:
> On Sat, Apr 05, 2003 at 06:01:16PM +0300, Ognyan Kulev wrote:
> > The case when #if !defined(__GLIBC__) is not legitimate either.  The 
> > only real solution is to use strcpy even for constant strings.  Node 
> > "Local Socket example" of glibc info shows one way how to deal with 
> > strings.  I beleive one line must be added:
> >
> > sub.sun_path[sizeof(sun.sun_path) - 1] = '\0';
>
> not in this case. note that sun_path is _not_ a nul-terminated string.
> in Glibc, it's a char (not a pointer to char) that can hold no more and
> no less than 108 characters, where the nul-terminator is irrelevant.
>
> (see the glibc docs about sockaddr_un)

sun_path is array of chars that holds C string.  C strings always end in
 nul character.  I agree that if you use SUN_LEN the terminating NUL
character is *not* included but it's *used* by SUN_LEN[1].  (FreeBSD man
page doesn't mention this.)  I agree that this line is redundant as long
 as you pass `sizeof (struct sockaddr_un)' but not `SUN_LEN (su)' to
socket functions.  And I agree that when you get sockaddr_un from kernel
sun_path won't terminate in NUL character.  I've just changed this in
the page.

[1] http://netbsd.gw.com/cgi-bin/man-cgi?unix++NetBSD-current

> > This covers the case when strncpy is applied to longer strings.
>
> when strncpy is applied to longer strings, it will cut them off. this
> is as good as it gets now as there's a 108 char limit.

It won't add nul character for strings longer than 108 characters as
noted in the second paragraph about strncpy in glibc manual[1].  As I
said before, as long as you always use `sizeof (struct sockaddr_un)' it
doesn't matter if you set the 108th character to NUL.

[1] http://www.fifi.org/cgi-bin/info2www?(libc)Copying+and+Concatenation

> > The "108 limit" is not real limit.
>
> it is, see the docs:
>
>     `char sun_path[108]'
>           This is the file name to use.
>                                                                                 
>           *Incomplete:*  Why is 108 a magic number?  RMS suggests making
>           this a zero-length array and tweaking the following example
>           to use `alloca' to allocate an appropriate amount of storage
>           based on the length of the filename.
>
> > I'm not sure but I think that 
> > passing longer strings is OK as long as it's reflected in sa_len.
>
> you're confused with other C libraries. some BSDs have sa_len but we
> don't. look at the diff for package "fam" in the BTS for an example
> of code for FreeBSD.

I've not written that part well: I meant sa_len *variable* in my last
example, not struct's field *sun_len*.  By sa_len I meant SUN_LEN (sa).

http://mail-index.netbsd.org/tech-kern/1997/02/25/0014.html
This is something I'm not sure about, but sun_len doesn't need to be set
by programmer even on BSDs.

> our implementation provides that sun_path is 108 chars long. note that
> sun_path is not a pointer to char so you can't just allocate your string
> in it. It's a memory space of 108 chars, and you can't readdress it
> (i have tried to assign sun_path, which doesn't work) so your only
> chance is to fill the current location with 108 chars. this is what
> strncpy does so it should be ok.

That's the whole point of RMS's suggestion: it's best to be char[0] and
we should always do alloc as in the last example.  We can have path
names longer than 108 characters *on GNU systems*.  I agree that we can
say that the third (last) example must be used in GNU systems and the
second example must be used in all other operating systems.

> if my explanation satisfies you, please revert your changes.

It doesn't completely satisfy me ;-)  That's why I move this discussion
into #187391 :-)

> and thanks for your participation in "PortingIssues", i really
> appreciate it :)

That's my 2 cents for quality documentation about the Hurd :-)

Regards
--
Ognyan Kulev <ogi@fmi.uni-sofia.bg>, "\"Programmer\""