Re: Bug#187391: PortingIssues sockaddr_un

[Robert Millan]

retitle 187391 libc0.3-dev: sockaddr_un.sun_path can't be assigned a "const 
char *"
thanks

On Mon, Apr 14, 2003 at 03:41:30PM +0200, Niels Möller wrote:
> 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.

yes, this wouldn't matter if you could modify the pointer (as you point
below) to allocate space, but we can't so we had to stick with those 108.

> 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.

this is the second unrelated problem.. and as Ognyan pointed this is
filesystem related.

> 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.

which is granted. the other problem is that "const char *" is not accepted
in sockaddr_un.sun_path

> 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.

THERE :). see the first message in bug #187391 for details.

after i hit this bug, i figured out a workaround by using strncpy on
sun_path, and added it to the Wiki. we were actualy discussing on
the workaround i wrote.

after you clued me in that there's no limit for sun_path on GNU,
the discussion makes a bit more sense to see if we can take profit
from it in the code, although i doubt this can be exploited since
code out there will impose a 108 char limitation already.

> > 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.

no why? a "const char *" works fine on GNU/Linux. i don't see why
it should not work on GNU too.

> 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.

ok, let me retitle this bug so it illustrates your summary

-- 
Robert Millan

make: *** No rule to make target `war'.  Stop.

Another world is possible - Just say no to genocide