Re: Bug#187391: PortingIssues sockaddr_un

[Niels Möller]

Robert Millan <zeratul2@wanadoo.es> writes:

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

Ok, rereading that, I also see that there's no problem with gcc. It's
only g++ that breaks. So it's a bug somewhere in the c++ development
environment (with which I'm not terribly familiar).

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

Perhaps I misunderstood you. My point was that the sun_path in
sockaddr_un should be a char array (just like now), with some
arbitrary length. Then

  char *f = "foo";
  struct sockaddr_un s1 = { AF_UNIX, "foo" };  /* A. Should work */
  struct sockaddr_un s2 = { AF_UNIX, f };      /* B. Can't work */

B can't work, because it tries to initialize a char array from a char
pointer and that's not valid C. One needs strncpy for that. I got the
impression that you proposed changing the definition of sockaddr_un to

  struct sockaddr_un
    {
      sa_family_t sun_family;
      char *sun_path;  /* Pointer here, replacing the traditional array */
    };

Then both A and B would work, but practically all other code that uses
AF_UNIX sockets would break, so we really can't do that.

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

I think it is also important to note that it's related to g++. Sorry I
forgot that half way through this thread.

Regards,
/Niels