Re: Bug#187391: PortingIssues sockaddr_un

[Robert Millan]

On Mon, Apr 14, 2003 at 04:19:03PM +0300, Ognyan Kulev wrote:
> 
> This arbitrary limit (108) is just for *nix compatibility -- programs 
> expect to be able to do something like:
> 
> struct sockaddr_un su;
> su.sun_family = AF_LOCAL;
> strcpy (su.sun_path, "/path/to/socket"); /* for constant strings!  */

no, the initial allocated size is 108. you're right in that you _should_
be able to reallocate it in the pointer, but for some reason you can't.

particularly on GNU, it happens that the implementation doesn't match
the api and the limit is different.. then as you said it makes sense
to calculate it.

> Ext2 has limitation on path name _component_ and this limit is 255.  So 
> we have strlen("/tmp/")=5 + 255 = 260.  This limitation is in ext2, not 
> in sockaddr_un.  If the prefix was something like "/tmp/1234/" then the 
> limit would be 265.

oh, i see.

> >2- assuming there's no limitation on GNU, which is wrong and will lead
> >to overflows.
> 
> This is exactly the case.  All we need to do is to alloca sockaddr_un 
> with the correct size (that can be of any length) and fill it.

you mean alloca sockaddr_un or alloca sockaddr_un.sun_path?

because sockaddr_un.sun_path has that nasty bug that prevents you from
assigning a pointer to it.

> >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.
> 
> I have a question for you: how do you interpret RMS's suggestion to use 
> `alloca'?  Nowhere he mentions that alloca is for sun_path, and I think 
> that it is about the whole sockaddr_un.

RMS's suggestion refers to sun_path, and is based on the assumption that
there isn't a weird bug that prevents you from assigning new pointers to
a sockaddr_un.sun_path

aside from that, i agree it's much better to assign a dynamicaly allocated
string to sun_path rather than strncpy'ing a 108-limited string to it.

however, strncpy'ing a 108-limited string is still the only solution that
adheres to the API docs. but the GNU implementation doesn't match the
API docs anyway so... oh well (i'm getting a headache).

> Again, there is no such limit in GNU, exactly like not having PATH_MAX.

not when we can allocate it manualy..

-- 
Robert Millan

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

Another world is possible - Just say no to genocide