Re: Bug#187391: PortingIssues sockaddr_un

[Niels Möller]

Robert Millan <zeratul2@wanadoo.es> writes:

> By using Niels' test program it comes out that on GNU/Linux you have
> exactly 108 chars and on GNU you have more space. In my system it came
> to be that i have 260 bytes, but attempting to use 261 fails.

Well, there are two limits here: The "userspace" limit of 108 bytes.
To me, this limit seems utterly artificial, and can be ignored. Just
use alloca and forget about it.

Then there's the "kernel" limit (as implemented either in the kernel,
in the glibc glue, or in the hurd case, inside the pfunix server).
On the hurd, there probably shouldn't be any such limit, if there is
one now, perhaps that should be filed as a pfunix bug.

All that's needed for compatibility with other systems is that any
limits that we have is larger than (or equal) to the traditional 108
characters.

> our issue is this simple: a "const char *" satisfies sun_path on
> GNU/Linux but doesn't satisfy sun_path on GNU.

Do I understand you correctly, if the problem here is that the
constant initializer

  sockaddr_un sun = { AF_UNIX, "/path/to/socket" }; /*  X  */

gives a compilation error on the Hurd? What was the error message? To
me, that seems like a bug in glibc or perhaps even gcc, that is
totally unrelated to the limit above. I don't understand why the
compiler complains (it's perfectly fine in ANSI-C to initialize a char
array member from a string literal), but one has to figure that out
before the bug can be fixed.

> of course, a better solution could be to allow the pointer in
> sockaddr_un.sun_path to be replaced by a const char * for GNU. then we
> wouldn't have to fix anything else.

That would break source compatibility with posix, and binary
compatibility with gnu/linux. So that's not an option.

So my summary is this: We need to figure out why the compiler doesn't
like the perfectly valid initializer X above. The other issues that
have been touched in this thread (various limits on the size of
sun_path, NUL-termination, the SUN_LEN macro, the non-presence of the
sun_len member in struct sockaddr_un), are mostly irrelevant for
solving the problem at hand.

Regards,
/Niels