Bug#187391: PortingIssues sockaddr_un
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\""
Reply to: