Re: Bug#187391: PortingIssues sockaddr_un

[Stephan Trebels]

So where is the bug then, is there specified anywhere, that the sun_path
must be assignable?  How about the following code, which should work
fine with variable storage.

#define _POSIX_SOURCE
#define _GNU_SOURCE
#include <unistd.h>
#include <sys/socket.h>
#include <sys/un.h>

int main() {
  const char *sun_path = "/what/ever/you/want";
  struct sockaddr_un *sunp = 0;
  size_t sun_length = (sizeof(*sunp) - 
                       sizeof(sunp->sun_path) +
                       strlen(sun_path));

  sunp = alloca(sun_length);
  memset(sunp, 0, sun_length);
  sunp->sun_family = AF_UNIX;
  strcpy(sunp->sun_path, sun_path);
  
  //use it...
}

Stephan

On Mon, 2003-04-14 at 17:19, Robert Millan wrote:
> 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
-- 
        Stephan Trebels <stephan@ncube.de>   Consultant
company: nCUBE Deutschland GmbH, Hanauer Str. 56, 80992 Munich, Germany
phone: cell:+49 172 8433111  office:+49 89 1498930  fax:+49 89 14989350