Debian Bug report logs - #187391
libc0.3-dev: sockaddr_un.sun_path can't be assigned a "const char *" when compiling with g++

Package: libc0.3-dev; Maintainer for libc0.3-dev is GNU Libc Maintainers <debian-glibc@lists.debian.org>; Source for libc0.3-dev is src:eglibc.

Reported by: Robert Millan <rmh@aybabtu.com>

Date: Thu, 3 Apr 2003 01:48:01 UTC

Severity: normal

Tags: patch

Reply or subscribe to this bug.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>, glibc@packages.qa.debian.org:
Bug#187391; Package libc0.3-dev. Full text and rfc822 format available.

Acknowledgement sent to Robert Millan <zeratul2@wanadoo.es>:
New Bug report received and forwarded. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>, glibc@packages.qa.debian.org. Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Robert Millan <zeratul2@wanadoo.es>
To: submit@bugs.debian.org
Cc: bug-hurd@gnu.org
Subject: libc0.3-dev: weirdness with sockaddr_un
Date: Thu, 3 Apr 2003 03:42:11 +0200
Package: libc0.3-dev
Severity: normal

hi!

the following code seems to be compliant with the Glibc documentation
referred to sockaddr_un, as it provides a char* as the second component
of the struct:

  #include <sys/socket.h>
  #include <sys/un.h>
  main ()
  {
    sockaddr_un test = { AF_LOCAL, "" };
  }

however, when built with g++ (and not with gcc) on GNU/Hurd, it reports
mismatch errors:

  test.c: In function `int main()':
  test.c:6: invalid conversion from `const char*' to `unsigned char'

which is strange that it expects a char when both the documentation
and <sys/un.h> agree that it should be a char*.

the code in question compiles fine on GNU/Linux.

-- 
Robert Millan

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

Another world is possible - Just say no to genocide



Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>, glibc@packages.qa.debian.org:
Bug#187391; Package libc0.3-dev. Full text and rfc822 format available.

Acknowledgement sent to GOTO Masanori <gotom@debian.or.jp>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>, glibc@packages.qa.debian.org. Full text and rfc822 format available.

Message #10 received at 187391@bugs.debian.org (full text, mbox):

From: GOTO Masanori <gotom@debian.or.jp>
To: Robert Millan <zeratul2@wanadoo.es>, 187391@bugs.debian.org
Cc: bug-hurd@gnu.org
Subject: Re: Bug#187391: libc0.3-dev: weirdness with sockaddr_un
Date: Thu, 03 Apr 2003 20:22:14 +0900
At Thu, 3 Apr 2003 03:42:11 +0200,
Robert Millan wrote:
> the following code seems to be compliant with the Glibc documentation
> referred to sockaddr_un, as it provides a char* as the second component
> of the struct:
> 
>   #include <sys/socket.h>
>   #include <sys/un.h>
>   main ()
>   {
>     sockaddr_un test = { AF_LOCAL, "" };
>   }
> 
> however, when built with g++ (and not with gcc) on GNU/Hurd, it reports
> mismatch errors:
> 
>   test.c: In function `int main()':
>   test.c:6: invalid conversion from `const char*' to `unsigned char'
d
> 
> which is strange that it expects a char when both the documentation
> and <sys/un.h> agree that it should be a char*.
> 
> the code in question compiles fine on GNU/Linux.

SUSv3 describes sockaddr_un has at least sun_family and sun_path.  The
definition of 4.4BSD adds sun_len.  Hurd uses the generic definition,
and other use the 4.4BSD's.  Historically, BSD (4.2?) does not have
sun_len member in struct sockaddr_un.  Nowadays BSD (after 4.3?) has
sockaddr_un.sun_len.

sockaddr_un can be variable length, so I think your program style
should be avoided.  I think it's appropriate to use the substitution
like test.sun_family=AF_LOCAL, or so. 

I don't think it's bug.  I would like to close your report, ok?

Regards,
-- gotom



Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>, glibc@packages.qa.debian.org:
Bug#187391; Package libc0.3-dev. Full text and rfc822 format available.

Acknowledgement sent to GOTO Masanori <gotom@debian.or.jp>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>, glibc@packages.qa.debian.org. Full text and rfc822 format available.

Message #15 received at 187391@bugs.debian.org (full text, mbox):

From: GOTO Masanori <gotom@debian.or.jp>
To: Robert Millan <zeratul2@wanadoo.es>, 187391@bugs.debian.org
Cc: bug-hurd@gnu.org
Subject: Re: Bug#187391: libc0.3-dev: weirdness with sockaddr_un
Date: Thu, 03 Apr 2003 20:29:43 +0900
At Thu, 03 Apr 2003 20:25:19 +0900,
GOTO Masanori wrote:
> 
> At Thu, 3 Apr 2003 03:42:11 +0200,
> Robert Millan wrote:
> > however, when built with g++ (and not with gcc) on GNU/Hurd, it reports
> > mismatch errors:
> > 
> >   test.c: In function `int main()':
> >   test.c:6: invalid conversion from `const char*' to `unsigned char'
> d
> > 
> > which is strange that it expects a char when both the documentation
> > and <sys/un.h> agree that it should be a char*.
> > 
> > the code in question compiles fine on GNU/Linux.
> 
> SUSv3 describes sockaddr_un has at least sun_family and sun_path.  The
> definition of 4.4BSD adds sun_len.  Hurd uses the generic definition,
> and other use the 4.4BSD's.  Historically, BSD (4.2?) does not have
> sun_len member in struct sockaddr_un.  Nowadays BSD (after 4.3?) has
> sockaddr_un.sun_len.
> 
> sockaddr_un can be variable length, so I think your program style
> should be avoided.  I think it's appropriate to use the substitution
> like test.sun_family=AF_LOCAL, or so. 
> 
> I don't think it's bug.  I would like to close your report, ok?

BTW, I don't know why Hurd uses the generic definition.  If it's not
intentional, we can say it's a bug.

Regards,
-- gotom



Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>, glibc@packages.qa.debian.org:
Bug#187391; Package libc0.3-dev. Full text and rfc822 format available.

Acknowledgement sent to Robert Millan <zeratul2@wanadoo.es>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>, glibc@packages.qa.debian.org. Full text and rfc822 format available.

Message #20 received at 187391@bugs.debian.org (full text, mbox):

From: Robert Millan <zeratul2@wanadoo.es>
To: GOTO Masanori <gotom@debian.or.jp>
Cc: 187391@bugs.debian.org, bug-hurd@gnu.org
Subject: Re: Bug#187391: libc0.3-dev: weirdness with sockaddr_un
Date: Thu, 3 Apr 2003 14:06:43 +0200
On Thu, Apr 03, 2003 at 08:29:43PM +0900, GOTO Masanori wrote:
> At Thu, 03 Apr 2003 20:25:19 +0900,
> GOTO Masanori wrote:
> > 
> > SUSv3 describes sockaddr_un has at least sun_family and sun_path.  The
> > definition of 4.4BSD adds sun_len.  Hurd uses the generic definition,
> > and other use the 4.4BSD's.  Historically, BSD (4.2?) does not have
> > sun_len member in struct sockaddr_un.  Nowadays BSD (after 4.3?) has
> > sockaddr_un.sun_len.
> > 
> > sockaddr_un can be variable length, so I think your program style
> > should be avoided.  I think it's appropriate to use the substitution
> > like test.sun_family=AF_LOCAL, or so. 
> > 
> > I don't think it's bug.  I would like to close your report, ok?
> 
> BTW, I don't know why Hurd uses the generic definition.  If it's not
> intentional, we can say it's a bug.

the generic definition that you describe matches with the described in
Glibc documentation (ie, short int sun_family and char sun_path[108]),
and the test code seems compliant with it:

  #include <sys/socket.h>
  #include <sys/un.h>
  main ()
  {
    sockaddr_un test = { AF_LOCAL, "" };
  }

i'll try using the substitution as you said -maybe that helps-, but it
still seems a bug to me in case the API doesn't match the docs.

thanks!

-- 
Robert Millan

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

Another world is possible - Just say no to genocide



Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>, glibc@packages.qa.debian.org:
Bug#187391; Package libc0.3-dev. Full text and rfc822 format available.

Acknowledgement sent to nisse@lysator.liu.se (Niels Möller):
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>, glibc@packages.qa.debian.org. Full text and rfc822 format available.

Message #25 received at 187391@bugs.debian.org (full text, mbox):

From: nisse@lysator.liu.se (Niels Möller)
To: Robert Millan <zeratul2@wanadoo.es>
Cc: 187391@bugs.debian.org, bug-hurd@gnu.org
Subject: Re: libc0.3-dev: weirdness with sockaddr_un
Date: 03 Apr 2003 14:10:52 +0200
Robert Millan <zeratul2@wanadoo.es> writes:

> the following code seems to be compliant with the Glibc documentation
> referred to sockaddr_un, as it provides a char* as the second component
> of the struct:

Where do you find the char *? A sockaddr_un contains the family
identifier followed by the filename *in place*. No pointers involved.
When passing a socklen_t and a sockaddr * to system calls[1] like bind
or connect, the sockaddr blob is copied into kernel space, and nothing
else. Storing pointers in the sockaddr would be useless. The glibc
manual I have around "Edition 0.10, last updated 2001-07-06, of `The
GNU C Library Reference Manual', for Version 2.2.x of the GNU C
Library" documents sockaddr_un like this:

     The structure for specifying socket names in the local namespace is
  defined in the header file `sys/un.h':
  
   - Data Type: struct sockaddr_un
       This structure is used to specify local namespace socket
       addresses.  It has the following members:
  
      `short int sun_family'
            This identifies the address family or format of the socket
            address.  You should store the value `AF_LOCAL' to designate
            the local namespace.  *Note Socket Addresses::.
  
      `char sun_path[108]'
            This is the file name to use.
  
            *Incomplete:*  Why is 108 a magic number?  RMS suggests making
            this a zero-length array and tweaking the following example
            to use `alloca' to allocate an appropriate amount of storage
            based on the length of the filename.

(AFAIK, the file name need not even be NUL-terminated, all that matters
is the socklen_t you pass around together with the sockaddr *).

>   #include <sys/socket.h>
>   #include <sys/un.h>
>   main ()
>   {
>     sockaddr_un test = { AF_LOCAL, "" };
>   }

What you're trying to do is *not* to initialize a char *, but a
character array. It should be ok to intialize a char array from
a string literal, though, so I don't quite understand the g++ error.
But I don't really use C++ either.

>   test.c: In function `int main()':
>   test.c:6: invalid conversion from `const char*' to `unsigned char'

/Niels

[1] Ok, on the hurd, they're not really system calls, but the
    interface is the same, and we're supposed to be binary compatible
    and all.



Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>, glibc@packages.qa.debian.org:
Bug#187391; Package libc0.3-dev. Full text and rfc822 format available.

Acknowledgement sent to Jeff Bailey <jbailey@nisa.net>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>, glibc@packages.qa.debian.org. Full text and rfc822 format available.

Message #30 received at 187391@bugs.debian.org (full text, mbox):

From: Jeff Bailey <jbailey@nisa.net>
To: GOTO Masanori <gotom@debian.or.jp>
Cc: Robert Millan <zeratul2@wanadoo.es>, 187391@bugs.debian.org, bug-hurd@gnu.org
Subject: Re: Bug#187391: libc0.3-dev: weirdness with sockaddr_un
Date: Thu, 3 Apr 2003 06:02:12 -0800
On Thu, Apr 03, 2003 at 08:29:43PM +0900, GOTO Masanori wrote:

> BTW, I don't know why Hurd uses the generic definition.  If it's not
> intentional, we can say it's a bug.

Or should the generic definition be changed?  I'll add it to my TODO
list to look at.

-- 
Are you going to stay vegeterian?
    Are you going to start eating human flesh?
(from http://www.moshez.org/vegeterian.html)



Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>, glibc@packages.qa.debian.org:
Bug#187391; Package libc0.3-dev. Full text and rfc822 format available.

Acknowledgement sent to Robert Millan <zeratul2@wanadoo.es>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>, glibc@packages.qa.debian.org. Full text and rfc822 format available.

Message #35 received at 187391@bugs.debian.org (full text, mbox):

From: Robert Millan <zeratul2@wanadoo.es>
To: Jeff Bailey <jbailey@nisa.net>, GOTO Masanori <gotom@debian.or.jp>, 187391@bugs.debian.org, bug-hurd@gnu.org
Subject: Re: Bug#187391: libc0.3-dev: weirdness with sockaddr_un
Date: Thu, 3 Apr 2003 20:44:17 +0200
On Thu, Apr 03, 2003 at 06:02:12AM -0800, Jeff Bailey wrote:
> On Thu, Apr 03, 2003 at 08:29:43PM +0900, GOTO Masanori wrote:
> 
> > BTW, I don't know why Hurd uses the generic definition.  If it's not
> > intentional, we can say it's a bug.
> 
> Or should the generic definition be changed?  I'll add it to my TODO
> list to look at.

note what the docs say in reference to `char sun_path[108]':
                                                                               
          *Incomplete:*  Why is 108 a magic number?  RMS suggests making
          this a zero-length array and tweaking the following example
          to use `alloca' to allocate an appropriate amount of storage
          based on the length of the filename.

-- 
Robert Millan

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

Another world is possible - Just say no to genocide



Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>, glibc@packages.qa.debian.org:
Bug#187391; Package libc0.3-dev. Full text and rfc822 format available.

Acknowledgement sent to nisse@lysator.liu.se (Niels Möller):
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>, glibc@packages.qa.debian.org. Full text and rfc822 format available.

Message #40 received at 187391@bugs.debian.org (full text, mbox):

From: nisse@lysator.liu.se (Niels Möller)
To: Robert Millan <zeratul2@wanadoo.es>
Cc: Jeff Bailey <jbailey@nisa.net>, GOTO Masanori <gotom@debian.or.jp>, 187391@bugs.debian.org, bug-hurd@gnu.org
Subject: Re: Bug#187391: libc0.3-dev: weirdness with sockaddr_un
Date: 03 Apr 2003 21:17:00 +0200
Robert Millan <zeratul2@wanadoo.es> writes:

> note what the docs say in reference to `char sun_path[108]':
> 
>           *Incomplete:*  Why is 108 a magic number?  RMS suggests making
>           this a zero-length array and tweaking the following example
>           to use `alloca' to allocate an appropriate amount of storage
>           based on the length of the filename.

And in any case, adding a sun_len element to the structure seems very
redundant. All functions using sockaddr:s already take a separate
socklen_t argument, as sockaddr:es in general have varying length.
Only oddity with sockaddr_un is that the length can vary also between
addresses within the same address family.

  socklen_t sa_len = offsetof(struct sockaddr_un, sun_path)
                     + filename_length + 1;
  
  sockaddr_un sa = alloca(sa_len);

should work fine for arbitrary length filenames, no matter if or how
the magic number 108 in the declaration is replaced.

(And I still think that the + 1 for a terminating NUL isn't really
necessary, although I'm not sure what the standard says on that).

/Niels



Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>, glibc@packages.qa.debian.org:
Bug#187391; Package libc0.3-dev. Full text and rfc822 format available.

Acknowledgement sent to Ognyan Kulev <ogi@fmi.uni-sofia.bg>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>, glibc@packages.qa.debian.org. Full text and rfc822 format available.

Message #45 received at 187391@bugs.debian.org (full text, mbox):

From: Ognyan Kulev <ogi@fmi.uni-sofia.bg>
To: 187391@bugs.debian.org
Subject: Re: PortingIssues sockaddr_un
Date: Sun, 06 Apr 2003 18:14:27 +0300
This discussion is about 
http://hurd.gnufans.org/bin/view/Distrib/PortingIssues#Uncompliant_use_of_sockaddr_un_t
We need an agreement about what should be in this page.

Robert Millan wrote:
> On Sat, Apr 05, 2003 at 06:01:16PM +0300, Ognyan Kulev wrote:
>>The case when #if !defined(__GLIBC__) is not legitimate either.  The 
>>only real solution is to use strcpy even for constant strings.  Node 
>>"Local Socket example" of glibc info shows one way how to deal with 
>>strings.  I beleive one line must be added:
>>
>>sub.sun_path[sizeof(sun.sun_path) - 1] = '\0';
> 
> not in this case. note that sun_path is _not_ a nul-terminated string.
> in Glibc, it's a char (not a pointer to char) that can hold no more and
> no less than 108 characters, where the nul-terminator is irrelevant.
> 
> (see the glibc docs about sockaddr_un)

sun_path is array of chars that holds C string.  C strings always end in 
 nul character.  I agree that if you use SUN_LEN the terminating NUL 
character is *not* included but it's *used* by SUN_LEN[1].  (FreeBSD man 
page doesn't mention this.)  I agree that this line is redundant as long 
 as you pass `sizeof (struct sockaddr_un)' but not `SUN_LEN (su)' to 
socket functions.  And I agree that when you get sockaddr_un from kernel 
sun_path won't terminate in NUL character.  I've just changed this in 
the page.

[1] http://netbsd.gw.com/cgi-bin/man-cgi?unix++NetBSD-current

>>This covers the case when strncpy is applied to longer strings.
> 
> when strncpy is applied to longer strings, it will cut them off. this
> is as good as it gets now as there's a 108 char limit.

It won't add nul character for strings longer than 108 characters as 
noted in the second paragraph about strncpy in glibc manual[1].  As I 
said before, as long as you always use `sizeof (struct sockaddr_un)' it 
doesn't matter if you set the 108th character to NUL.

[1] http://www.fifi.org/cgi-bin/info2www?(libc)Copying+and+Concatenation

>>The "108 limit" is not real limit.
> 
> it is, see the docs:
> 
>     `char sun_path[108]'
>           This is the file name to use.
>                                                                                 
>           *Incomplete:*  Why is 108 a magic number?  RMS suggests making
>           this a zero-length array and tweaking the following example
>           to use `alloca' to allocate an appropriate amount of storage
>           based on the length of the filename.
>
>>I'm not sure but I think that 
>>passing longer strings is OK as long as it's reflected in sa_len.
>
> you're confused with other C libraries. some BSDs have sa_len but we
> don't. look at the diff for package "fam" in the BTS for an example
> of code for FreeBSD.

I've not written that part well: I meant sa_len *variable* in my last 
example, not struct's field *sun_len*.  By sa_len I meant SUN_LEN (sa).

http://mail-index.netbsd.org/tech-kern/1997/02/25/0014.html
This is something I'm not sure about, but sun_len doesn't need to be set 
by programmer even on BSDs.

> our implementation provides that sun_path is 108 chars long. note that
> sun_path is not a pointer to char so you can't just allocate your string
> in it. It's a memory space of 108 chars, and you can't readdress it
> (i have tried to assign sun_path, which doesn't work) so your only
> chance is to fill the current location with 108 chars. this is what
> strncpy does so it should be ok.

That's the whole point of RMS's suggestion: it's best to be char[0] and 
we should always do alloc as in the last example.  We can have path 
names longer than 108 characters *on GNU systems*.  I agree that we can 
say that the third (last) example must be used in GNU systems and the 
second example must be used in all other operating systems.

> if my explanation satisfies you, please revert your changes.

It doesn't completely satisfy me ;-)  That's why I move this discussion 
into #187391 :-)

> and thanks for your participation in "PortingIssues", i really
> appreciate it :)

That's my 2 cents for quality documentation about the Hurd :-)

Regards
-- 
Ognyan Kulev <ogi@fmi.uni-sofia.bg>, "\"Programmer\""




Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>, glibc@packages.qa.debian.org:
Bug#187391; Package libc0.3-dev. Full text and rfc822 format available.

Acknowledgement sent to Ognyan Kulev <ogi@fmi.uni-sofia.bg>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>, glibc@packages.qa.debian.org. Full text and rfc822 format available.

Message #50 received at 187391@bugs.debian.org (full text, mbox):

From: Ognyan Kulev <ogi@fmi.uni-sofia.bg>
To: bug-hurd@gnu.org, 187391@bugs.debian.org
Subject: Re: Bug#187391: PortingIssues sockaddr_un
Date: Mon, 07 Apr 2003 16:48:07 +0300
Ognyan Kulev wrote:
> This discussion is about
> http://hurd.gnufans.org/bin/view/Distrib/PortingIssues#Uncompliant_use_of_sockaddr_un_t 
> 
> We need an agreement about what should be in this page.
> 
> Robert Millan wrote:
> 
>> On Sat, Apr 05, 2003 at 06:01:16PM +0300, Ognyan Kulev wrote:
>>
>>> sub.sun_path[sizeof(sun.sun_path) - 1] = '\0';

I've changed my mind about this, so I've added it again.

I understand that my changes are somewhat intrusive to what Robert 
Millan wrote, but I wouldn't do it if I didn't beleive they are right. 
Please say your mind about the current text.

 Uncompliant use of sockaddr_un

The following declaration:

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

won't work on GNU/Hurd. The Glibc API requires that the second parameter 
of a sockaddr_un struct is array of chars, but NOT pointer to array of 
chars. So we have to copy them directly into the sun_path address. Glibc 
wants string of chars there that doesn't need to end in nul character 
_and_ correct size of sockaddr_un passed to socket functions. When 
calling socket functions one should always use SUN_LEN (su) for the 
sockaddr length argument. An example:

sockaddr_un su;
/* AF_LOCAL is the canonical flag in Glibc.
   Use AF_UNIX if you want compatibility.  */
su.sun_family = AF_LOCAL;
/* Copy the string into sun_path. It must be
   no longer than approximately 100 characters. */
strcpy (su.sun_path, "/path/to/socket");

SUN_LEN macro is not defined in The Single UNIX Specification Version 3 
(see sys/un.h manpage). You can use the following definition to handle 
this case (definition taken from NetBSD):

#ifndef SUN_LEN
#define SUN_LEN(su) \
   (sizeof(*(su)) - sizeof((su)->sun_path) + \
   strlen((su)->sun_path))
#endif

If you have pointer to array of characters as file name, you'd better 
use the following code to set sun_path:

strncpy (su.sun_path, filename, sizeof (su.sun_path));
su.sun_path[sizeof (su.sun_path) - 1] = '\0';

If you expect file name longer than approximately 100 characters, use 
the following code. This is the recommended code for GNU systems. You 
can include it whenever __GLIBC__ is defined.

/* `offsetof', `alloca' and `AF_LOCAL' may not
   be available everywhere.  */
socklen_t su_len = offsetof (struct sockaddr_un, sun_path)
                   + strlen (filename) + 1;
struct sockaddr_un *su = alloca (su_len);
su->sun_family = AF_LOCAL;
strcpy (su->sun_path, filename);

NOTE: the current API is subject to change, see the notes in Glibc's 
docs ("info libc" and search for sockaddr_un) and Debian bug #187391.

Regards
-- 
Ognyan Kulev <ogi@fmi.uni-sofia.bg>, "\"Programmer\""




Information forwarded to glibc@packages.qa.debian.org:
Bug#187391; Package libc0.3-dev. Full text and rfc822 format available.

Acknowledgement sent to Robert Millan <zeratul2@wanadoo.es>:
Extra info received and filed, but not forwarded. Copy sent to glibc@packages.qa.debian.org. Full text and rfc822 format available.

Message #55 received at 187391-quiet@bugs.debian.org (full text, mbox):

From: Robert Millan <zeratul2@wanadoo.es>
To: Ognyan Kulev <ogi@fmi.uni-sofia.bg>
Cc: bug-hurd@gnu.org, 187391-quiet@bugs.debian.org
Subject: Re: Bug#187391: PortingIssues sockaddr_un
Date: Thu, 10 Apr 2003 21:27:20 +0200
On Mon, Apr 07, 2003 at 04:48:07PM +0300, Ognyan Kulev wrote:
> 
> sockaddr_un su;
> /* AF_LOCAL is the canonical flag in Glibc.
>    Use AF_UNIX if you want compatibility.  */
> su.sun_family = AF_LOCAL;
> /* Copy the string into sun_path. It must be
>    no longer than approximately 100 characters. */
> strcpy (su.sun_path, "/path/to/socket");

this is wrong, there is no garantee that "/path/to/socket" isn't longer
than 108 chars, then su.sun_path would overflow.

> SUN_LEN macro is not defined in The Single UNIX Specification Version 3 
> (see sys/un.h manpage).

we're talking about Glibc, which may or may not adhere to standards, but
has its own way of doing this. refer to the official Glibc documentation
in info format. the manpages from the "Linux programmer's manual" are made
by third parties outside Glibc developement (probably as a pretension that
their "Linux system" is not a variant of GNU), and are crappled with serious
bugs (see #152136) that help introducing programming errors.

according to the Glibc docs, sun_path is not defined by SUN_LEN, but
has a fixed length of 108 chars.

-- 
Robert Millan

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

Another world is possible - Just say no to genocide



Information forwarded to glibc@packages.qa.debian.org:
Bug#187391; Package libc0.3-dev. Full text and rfc822 format available.

Acknowledgement sent to Ognyan Kulev <ogi@fmi.uni-sofia.bg>:
Extra info received and filed, but not forwarded. Copy sent to glibc@packages.qa.debian.org. Full text and rfc822 format available.

Message #60 received at 187391-quiet@bugs.debian.org (full text, mbox):

From: Ognyan Kulev <ogi@fmi.uni-sofia.bg>
To: Robert Millan <zeratul2@wanadoo.es>
Cc: bug-hurd@gnu.org, 187391-quiet@bugs.debian.org
Subject: Re: Bug#187391: PortingIssues sockaddr_un
Date: Sun, 13 Apr 2003 16:19:53 +0300
Robert Millan wrote:
> On Mon, Apr 07, 2003 at 04:48:07PM +0300, Ognyan Kulev wrote:
>
>>SUN_LEN macro is not defined in The Single UNIX Specification Version 3 
>>(see sys/un.h manpage).
> 
> we're talking about Glibc, which may or may not adhere to standards, but
> has its own way of doing this.

Yes, what I had written was _portability_ issue but not _porting_ issue. 
 I've removed SUN_LEN definition from the page.

> this is wrong, there is no garantee that "/path/to/socket" isn't longer
> than 108 chars, then su.sun_path would overflow.

Now I've made it clear in the page that this example is about constant C 
string that one is sure to be of length no longer than 100.

> according to the Glibc docs, sun_path is not defined by SUN_LEN, but
> has a fixed length of 108 chars.

I hope that the following example will convince you that in GNU/Hurd you 
are not limited to 108 characters.  It works on the Hurd, but fails on 
GNU/Linux with "Invalid argument").

#include <stddef.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/socket.h>
#include <sys/un.h>

#define FN_MAX	300

void
fatal (const char *where)
{
  perror (where);
  exit (EXIT_FAILURE);
}

int
main (void)
{
  char filename[FN_MAX];
  int sock;
  struct sockaddr_un *su;
  int i;

  sock = socket (PF_LOCAL, SOCK_DGRAM, 0);
  if (sock < 0)
    fatal ("socket");

  strcpy (filename, "/tmp/");
  for (i = 0; i < 200; i++)
    strcat (filename, "x");
  printf ("%s\n", filename);

  su = alloca (offsetof (struct sockaddr_un, sun_path)
	       + strlen (filename) + 1);
  su->sun_family = AF_LOCAL;
  strcpy (su->sun_path, filename);
  if (bind (sock, (struct sockaddr *)su, SUN_LEN (su)))
    fatal ("bind");

  if (close (sock))
    fatal ("close");

  return EXIT_SUCCESS;
}

Regards
-- 
Ognyan Kulev <ogi@fmi.uni-sofia.bg>, "\"Programmer\""




Information forwarded to glibc@packages.qa.debian.org:
Bug#187391; Package libc0.3-dev. Full text and rfc822 format available.

Acknowledgement sent to nisse@lysator.liu.se (Niels Möller):
Extra info received and filed, but not forwarded. Copy sent to glibc@packages.qa.debian.org. Full text and rfc822 format available.

Message #65 received at 187391-quiet@bugs.debian.org (full text, mbox):

From: nisse@lysator.liu.se (Niels Möller)
To: Ognyan Kulev <ogi@fmi.uni-sofia.bg>
Cc: Robert Millan <zeratul2@wanadoo.es>, 187391-quiet@bugs.debian.org, bug-hurd@gnu.org
Subject: Re: Bug#187391: PortingIssues sockaddr_un
Date: 13 Apr 2003 22:07:32 +0200
Ognyan Kulev <ogi@fmi.uni-sofia.bg> writes:

> I hope that the following example will convince you that in GNU/Hurd
> you are not limited to 108 characters.  It works on the Hurd, but
> fails on GNU/Linux with "Invalid argument").

Interesting, I didn't know linux had this silly limit. I've tried with
the below test program, which avoids the use of SUN_LEN, and which
demonstrates that NUL-termination is redundant, and that length up to
108 works fine. Tested on linux, where ./a.out 107 and ./a.out 108
works fine, but ./a.out 109 resultes in "bind: Invalid argument".

/Niels

----8<-------
#include <stddef.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/socket.h>
#include <sys/un.h>

void
fatal (const char *where)
{
   perror (where);
   exit (EXIT_FAILURE);
}

int
main (int argc, char **argv)
{
   int sock;
   struct sockaddr_un *su;
   int length;
   socklen_t size;

   if (argc < 2)
     length = 200;
   else
     length = atoi(argv[1]);

   sock = socket (PF_LOCAL, SOCK_DGRAM, 0);
   if (sock < 0)
     fatal ("socket");

   size = offsetof (struct sockaddr_un, sun_path) + length;
   su = alloca (size + 1); /* One extra for the non-NUL termination */

   memcpy(su->sun_path, "/tmp/", 5);
   memset(su->sun_path + 5, 'x', length - 5);
   su->sun_path[length] = 'a'; /* No NUL-termination */

   su->sun_family = AF_LOCAL;

   if (bind (sock, (struct sockaddr *)su, size))
     fatal ("bind");

   if (close (sock))
     fatal ("close");

   return EXIT_SUCCESS;
}



Information forwarded to glibc@packages.qa.debian.org:
Bug#187391; Package libc0.3-dev. Full text and rfc822 format available.

Acknowledgement sent to Ognyan Kulev <ogi@fmi.uni-sofia.bg>:
Extra info received and filed, but not forwarded. Copy sent to glibc@packages.qa.debian.org. Full text and rfc822 format available.

Message #70 received at 187391-quiet@bugs.debian.org (full text, mbox):

From: Ognyan Kulev <ogi@fmi.uni-sofia.bg>
To: 187391-quiet@bugs.debian.org
Cc: bug-hurd@gnu.org
Subject: Re: Bug#187391: PortingIssues sockaddr_un
Date: Mon, 14 Apr 2003 01:35:11 +0300
Niels Möller wrote:
> Interesting, I didn't know linux had this silly limit. I've tried with
> the below test program, which avoids the use of SUN_LEN, and which
> demonstrates that NUL-termination is redundant, and that length up to
> 108 works fine.

Yes, you either terminate sun_path with NUL and calculate the size with 
SUN_LEN, or you don't terminate it with NUL and calculate it yourself.

Using SUN_LEN is convenient for constant file names, and the latter 
approach can be used for the alloca thing where you know the exact size. 
 I just find "always use SUN_LEN" more convenient to remember :-)

Regards
-- 
Ognyan Kulev <ogi@fmi.uni-sofia.bg>, "\"Programmer\""




Information forwarded to glibc@packages.qa.debian.org:
Bug#187391; Package libc0.3-dev. Full text and rfc822 format available.

Acknowledgement sent to Robert Millan <zeratul2@wanadoo.es>:
Extra info received and filed, but not forwarded. Copy sent to glibc@packages.qa.debian.org. Full text and rfc822 format available.

Message #75 received at 187391-quiet@bugs.debian.org (full text, mbox):

From: Robert Millan <zeratul2@wanadoo.es>
To: Ognyan Kulev <ogi@fmi.uni-sofia.bg>
Cc: bug-hurd@gnu.org, 187391-quiet@bugs.debian.org
Subject: Re: Bug#187391: PortingIssues sockaddr_un
Date: Mon, 14 Apr 2003 13:51:20 +0200
On Sun, Apr 13, 2003 at 04:19:53PM +0300, Ognyan Kulev wrote:
> >this is wrong, there is no garantee that "/path/to/socket" isn't longer
> >than 108 chars, then su.sun_path would overflow.
> 
> Now I've made it clear in the page that this example is about constant C 
> string that one is sure to be of length no longer than 100.

No. you need to pay attention to the API docs. It says you are _garanteed_
an alloced space of 108 (no more, no less) bytes for sun_path.

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.

So, we have these choices:

1- strictly adhering to the API docs, and using 108 bytes (no less, if
the string is shorter fill with 0es with strncpy) for Glibc.
2- assuming there's no limitation on GNU, which is wrong and will lead
to overflows.
3- assuming the limit on GNU is 260 bytes, which is also wrong as you
have no garantee that this will change for future versions or other
system instances.
4- using SUN_LEN to determine it, which is wrong as SUN_LEN is unrelated
to sun_path's length. see the docs:

	You should compute the LENGTH parameter for a socket address in the
	local namespace as the sum of the size of the `sun_family' component
	and the string length (_not_ the allocation size!) of the file name
	string.  This can be done using the macro `SUN_LEN':

the problem here is that sun_path is NOT a nul-terminated string. if it
was, you could just use strlen to determine its string length. so in order
to obtain the string length, you can use SUN_LEN for that. but this _IS NOT_
the allocation size! the allocation size is in the sun_path definition
and it's a constant of 108 chars. it just means you have this:

sun_path[0..SUN_LEN] --> your string
sun_path[SUN_LEN..108] --> useless junk. typicaly 0es if you used strncpy

but we don't need to care about the string length at all, this is something
the program implementation should (or should not) do already. our issue
is this simple: a "const char *" satisfies sun_path on GNU/Linux but doesn't
satisfy sun_path on GNU. so the solution is to adhere strictly to the API
and copy the actual string instead of a pointer to it. this is why we need
to set the 108 byte limit in strncpy. (with a const char * there's no need
to hardcode a limit, just write short enough strings..)

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.

5- using an autoconf check to determine length of sockaddr_un.sun_len
in a sane way (say, iteratively attempting sizes untill it fails or
untill hell is frozen). this is correct and will allow GNU to use
its suposed 260 byte "advantage". but the rest of the code in all
programs is made sure to fit in 108 bytes, so this is a real overkill.


-- 
Robert Millan

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

Another world is possible - Just say no to genocide



Information forwarded to glibc@packages.qa.debian.org:
Bug#187391; Package libc0.3-dev. Full text and rfc822 format available.

Acknowledgement sent to Ognyan Kulev <ogi@fmi.uni-sofia.bg>:
Extra info received and filed, but not forwarded. Copy sent to glibc@packages.qa.debian.org. Full text and rfc822 format available.

Message #80 received at 187391-quiet@bugs.debian.org (full text, mbox):

From: Ognyan Kulev <ogi@fmi.uni-sofia.bg>
To: bug-hurd@gnu.org
Cc: 187391-quiet@bugs.debian.org
Subject: Re: Bug#187391: PortingIssues sockaddr_un
Date: Mon, 14 Apr 2003 16:19:03 +0300
Robert Millan wrote:
> On Sun, Apr 13, 2003 at 04:19:53PM +0300, Ognyan Kulev wrote:
> 
>>Now I've made it clear in the page that this example is about constant C 
>>string that one is sure to be of length no longer than 100.
> 
> No. you need to pay attention to the API docs. It says you are _garanteed_
> an alloced space of 108 (no more, no less) bytes for sun_path.

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!  */

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

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.

> So, we have these choices:
> 
> 1- strictly adhering to the API docs, and using 108 bytes (no less, if
> the string is shorter fill with 0es with strncpy) for Glibc.

This is not the GNU way.

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

> 3- assuming the limit on GNU is 260 bytes, which is also wrong as you
> have no garantee that this will change for future versions or other
> system instances.

As I showed above there is no such limit in GNU.

> 4- using SUN_LEN to determine it, which is wrong as SUN_LEN is unrelated
> to sun_path's length. see the docs:
>
>	You should compute the LENGTH parameter for a socket address in the
> 	local namespace as the sum of the size of the `sun_family' component
> 	and the string length (_not_ the allocation size!) of the file name
> 	string.  This can be done using the macro `SUN_LEN':
>

SUN_LEN is just a helper macro.  We can perfectly go without it.  For 
example:

size_t filename_len = strlen (filename);
socklen_t su_len =
  offsetof (struct sockaddr_un, sun_path) + filename_len;
struct sockaddr_un *su = alloca (su_len);
su->sun_family = AF_LOCAL;
memcpy (su->sun_path, filename, filename_len);
if (bind (sock, (struct sockaddr *)su, su_len))
...

> the problem here is that sun_path is NOT a nul-terminated string. if it
> was, you could just use strlen to determine its string length. so in order
> to obtain the string length, you can use SUN_LEN for that. but this _IS NOT_
> the allocation size! the allocation size is in the sun_path definition
> and it's a constant of 108 chars. it just means you have this:
> 
> sun_path[0..SUN_LEN] --> your string
> sun_path[SUN_LEN..108] --> useless junk. typicaly 0es if you used strncpy

SUN_LEN is macro that calculates what value you should pass to bind, 
etc.  It is not something like #define SUN_LEN 108.

> but we don't need to care about the string length at all, this is something
> the program implementation should (or should not) do already. our issue
> is this simple: a "const char *" satisfies sun_path on GNU/Linux but doesn't
> satisfy sun_path on GNU. so the solution is to adhere strictly to the API
> and copy the actual string instead of a pointer to it. this is why we need
> to set the 108 byte limit in strncpy. (with a const char * there's no need
> to hardcode a limit, just write short enough strings..)
> 
> 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.

> 5- using an autoconf check to determine length of sockaddr_un.sun_len
> in a sane way (say, iteratively attempting sizes untill it fails or
> untill hell is frozen). this is correct and will allow GNU to use
> its suposed 260 byte "advantage". but the rest of the code in all
> programs is made sure to fit in 108 bytes, so this is a real overkill.

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

Regards
-- 
Ognyan Kulev <ogi@fmi.uni-sofia.bg>, "\"Programmer\""




Information forwarded to glibc@packages.qa.debian.org:
Bug#187391; Package libc0.3-dev. Full text and rfc822 format available.

Acknowledgement sent to nisse@lysator.liu.se (Niels Möller):
Extra info received and filed, but not forwarded. Copy sent to glibc@packages.qa.debian.org. Full text and rfc822 format available.

Message #85 received at 187391-quiet@bugs.debian.org (full text, mbox):

From: nisse@lysator.liu.se (Niels Möller)
To: Robert Millan <zeratul2@wanadoo.es>
Cc: Ognyan Kulev <ogi@fmi.uni-sofia.bg>, 187391-quiet@bugs.debian.org, bug-hurd@gnu.org
Subject: Re: Bug#187391: PortingIssues sockaddr_un
Date: 14 Apr 2003 15:41:30 +0200
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



Information forwarded to glibc@packages.qa.debian.org:
Bug#187391; Package libc0.3-dev. Full text and rfc822 format available.

Acknowledgement sent to Robert Millan <zeratul2@wanadoo.es>:
Extra info received and filed, but not forwarded. Copy sent to glibc@packages.qa.debian.org. Full text and rfc822 format available.

Message #90 received at 187391-quiet@bugs.debian.org (full text, mbox):

From: Robert Millan <zeratul2@wanadoo.es>
To: Niels Möller <nisse@lysator.liu.se>
Cc: Ognyan Kulev <ogi@fmi.uni-sofia.bg>, 187391-quiet@bugs.debian.org, bug-hurd@gnu.org
Subject: Re: Bug#187391: PortingIssues sockaddr_un
Date: Mon, 14 Apr 2003 17:19:29 +0200
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



Changed Bug title. Request was from Robert Millan <zeratul2@wanadoo.es> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to glibc@packages.qa.debian.org:
Bug#187391; Package libc0.3-dev. Full text and rfc822 format available.

Acknowledgement sent to nisse@lysator.liu.se (Niels Möller):
Extra info received and filed, but not forwarded. Copy sent to glibc@packages.qa.debian.org. Full text and rfc822 format available.

Message #97 received at 187391-quiet@bugs.debian.org (full text, mbox):

From: nisse@lysator.liu.se (Niels Möller)
To: Robert Millan <zeratul2@wanadoo.es>
Cc: Ognyan Kulev <ogi@fmi.uni-sofia.bg>, 187391-quiet@bugs.debian.org, bug-hurd@gnu.org
Subject: Re: Bug#187391: PortingIssues sockaddr_un
Date: 14 Apr 2003 17:55:32 +0200
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



Information forwarded to glibc@packages.qa.debian.org:
Bug#187391; Package libc0.3-dev. Full text and rfc822 format available.

Acknowledgement sent to Robert Millan <zeratul2@wanadoo.es>:
Extra info received and filed, but not forwarded. Copy sent to glibc@packages.qa.debian.org. Full text and rfc822 format available.

Message #102 received at 187391-quiet@bugs.debian.org (full text, mbox):

From: Robert Millan <zeratul2@wanadoo.es>
To: Ognyan Kulev <ogi@fmi.uni-sofia.bg>
Cc: 187391-quiet@bugs.debian.org, bug-hurd@gnu.org
Subject: Re: Bug#187391: PortingIssues sockaddr_un
Date: Mon, 14 Apr 2003 17:40:23 +0200
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



Information forwarded to glibc@packages.qa.debian.org:
Bug#187391; Package libc0.3-dev. Full text and rfc822 format available.

Acknowledgement sent to Stephan Trebels <stephan@ncube.de>:
Extra info received and filed, but not forwarded. Copy sent to glibc@packages.qa.debian.org. Full text and rfc822 format available.

Message #107 received at 187391-quiet@bugs.debian.org (full text, mbox):

From: Stephan Trebels <stephan@ncube.de>
To: Robert Millan <zeratul2@wanadoo.es>
Cc: bug-hurd@gnu.org, 187391-quiet@bugs.debian.org
Subject: Re: Bug#187391: PortingIssues sockaddr_un
Date: 14 Apr 2003 17:15:38 +0200
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





Changed Bug title. Request was from Robert Millan <zeratul2@wanadoo.es> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to glibc@packages.qa.debian.org:
Bug#187391; Package libc0.3-dev. Full text and rfc822 format available.

Acknowledgement sent to Ognyan Kulev <ogi@fmi.uni-sofia.bg>:
Extra info received and filed, but not forwarded. Copy sent to glibc@packages.qa.debian.org. Full text and rfc822 format available.

Message #114 received at 187391-quiet@bugs.debian.org (full text, mbox):

From: Ognyan Kulev <ogi@fmi.uni-sofia.bg>
To: 187391-quiet@bugs.debian.org
Cc: bug-hurd@gnu.org
Subject: Re: Bug#187391: PortingIssues sockaddr_un
Date: Sat, 19 Apr 2003 15:41:55 +0300
Robert Millan wrote:
> 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.
> 
>>>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..

I've almost forgotten this thread :-)  Here I`ll try to make it clearer 
why alloca must be used in GNU systems.

What does classic *nix kernel expect from a sockaddr_un structure?  It 
expects the following sequence of bytes (let's forget sun_len in some 
BSDs -- this is irrelevant):

|..........|.....................................|
 sun_family sun_path

Where sun_family is some integer and sun_path is array of characters 
with length that is _not_ fixed and the last character is _not_ NUL. 
The length of this array of characters is calculated from the `socklen_t 
length' of bind (or whatever function is used).  To be precise, the 
formula is something like (where `length' is the parameter passed to 
`bind'):

length - offsetof (struct sockaddr_un, sun_path)

What happens in practice?  People do things like this:

struct sockaddr_un sun;
sun.sun_family = AF_LOCAL;
strcpy (sun.sun_path, "/tmp/my-socket");
... bind (sock, (struct sockaddr *)&sun, sizeof sun) ...
                                         ^^^^^^^^^^
You see, the `length' parameter is "not correct" because it represents 
sun_path as having more characters that it has in reality.  To cope with 
such cases when kernel wants sun_path it stops on the first NUL when 
there is such character.

Conclusion: In this cases it's better to use SUN_LEN to pass the correct 
`length' parameter, as this will give correct sockaddr size.

Now to the harder part: when you want to pass path name longer than 
roughly 100 characters.  This is possible.  See the above picture what 
kernels expect.  _I'm not talking about assigning pointer to sun_path._ 
 I'm talking about seeing sun_path as it is array with a different 
length.  When you use alloca as this:

socklen_t su_len = offsetof (struct sockaddr_un, sun_path)
                   + strlen (filename);
struct sockaddr_un *su = alloca (su_len);
su->sun_family = AF_LOCAL;
memcpy (su->sun_path, filename, strlen (filename));
... bind (sock, (struct sockaddr *)su, su_len) ...

your definition of `su' is like this:

|............|.................................|
| sun_family | sun_path                        |

but in reality, when strlen (filename) is greater than 108 and when the 
above code is used, it is something like this:

|............|....................................................|
| sun_family | sun_path                                           |

and it's OK by the kernel to get such (sctruct sockaddr_un *).

Classic *nix kernels will refuse such larger sockaddr_un when they look 
at the `length' parameter to bind, but GNU`s Not Unix.

I hope this clears up why alloca should be used in GNU.  And, again, I 
never talked about assigning pointer to sun_path, but about allocating 
struct sockaddr_un with custom size.

http://hurd.gnufans.org/bin/view/Distrib/PortingIssues is updated.

Regards
-- 
Ognyan Kulev <ogi@fmi.uni-sofia.bg>, "\"Programmer\""




Information forwarded to glibc@packages.qa.debian.org:
Bug#187391; Package libc0.3-dev. Full text and rfc822 format available.

Acknowledgement sent to Robert Millan <zeratul2@wanadoo.es>:
Extra info received and filed, but not forwarded. Copy sent to glibc@packages.qa.debian.org. Full text and rfc822 format available.

Message #119 received at 187391-quiet@bugs.debian.org (full text, mbox):

From: Robert Millan <zeratul2@wanadoo.es>
To: Ognyan Kulev <ogi@fmi.uni-sofia.bg>
Cc: 187391-quiet@bugs.debian.org, bug-hurd@gnu.org
Subject: Re: Bug#187391: PortingIssues sockaddr_un
Date: Tue, 22 Apr 2003 12:59:32 +0200
On Sat, Apr 19, 2003 at 03:41:55PM +0300, Ognyan Kulev wrote:
> 
> I've almost forgotten this thread :-)  Here I`ll try to make it clearer 
> why alloca must be used in GNU systems.
> 
> [...]

ok, i think i understand it now. please could you look at [1] and
make sure it's correct now? i'd say that:

- the third line (i wrote) is wrong
- the second line _should_ work on GNU, hence we have a bug in gcc
- the non-GLIBC example should use strncpy

[1] http://hurd.gnufans.org/bin/view/Distrib/PortingIssues#Uncompliant_use_of_sockaddr_un_t

-- 
Robert Millan

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

Another world is possible - Just say no to genocide



Information forwarded to glibc@packages.qa.debian.org:
Bug#187391; Package libc0.3-dev. Full text and rfc822 format available.

Acknowledgement sent to Ognyan Kulev <ogi@fmi.uni-sofia.bg>:
Extra info received and filed, but not forwarded. Copy sent to glibc@packages.qa.debian.org. Full text and rfc822 format available.

Message #124 received at 187391-quiet@bugs.debian.org (full text, mbox):

From: Ognyan Kulev <ogi@fmi.uni-sofia.bg>
To: 187391-quiet@bugs.debian.org
Cc: bug-hurd@gnu.org
Subject: Re: Bug#187391: PortingIssues sockaddr_un
Date: Tue, 22 Apr 2003 14:47:01 +0300
Robert Millan wrote:
> ok, i think i understand it now. please could you look at [1] and
> make sure it's correct now? i'd say that:
> 
> - the third line (i wrote) is wrong
> - the second line _should_ work on GNU, hence we have a bug in gcc

I didn't understand what lines you refer to.  I think "the second 
line" is about

struct sockaddr_un sun = { AF_LOCAL, "/path/to/socket" };

This can be a bug in G++, but it's bug in the program too because in 
BSDs you have one more field: sun_len (before sun_family), and this 
code will fail to compile too.  The portable solution is to not use 
such initialization because you aren't sure what fields are in struct 
sockaddr_un.

> - the non-GLIBC example should use strncpy

There is a question whether we should include _portability_ issues in 
our _porting_ page.  If we do, then we have to include example using 
strncpy.

Regards
-- 
Ognyan Kulev <ogi@fmi.uni-sofia.bg>, "\"Programmer\""




Information forwarded to glibc@packages.qa.debian.org:
Bug#187391; Package libc0.3-dev. Full text and rfc822 format available.

Acknowledgement sent to Robert Millan <zeratul2@wanadoo.es>:
Extra info received and filed, but not forwarded. Copy sent to glibc@packages.qa.debian.org. Full text and rfc822 format available.

Message #129 received at 187391-quiet@bugs.debian.org (full text, mbox):

From: Robert Millan <zeratul2@wanadoo.es>
To: Ognyan Kulev <ogi@fmi.uni-sofia.bg>
Cc: 187391-quiet@bugs.debian.org, bug-hurd@gnu.org
Subject: Re: Bug#187391: PortingIssues sockaddr_un
Date: Wed, 23 Apr 2003 17:36:58 +0200
On Tue, Apr 22, 2003 at 02:47:01PM +0300, Ognyan Kulev wrote:
> 
> I didn't understand what lines you refer to.  I think "the second 
> line" is about
> 
> struct sockaddr_un sun = { AF_LOCAL, "/path/to/socket" };
> 
> This can be a bug in G++,

ok then. i'll try to find a test case outside glibc to prove it's
a gcc [1] bug, then submit a bug against gcc [1].

[1] as in gnu compiler collection (i could reproduce it with gcc, too)

> but it's bug in the program too because in 
> BSDs you have one more field: sun_len (before sun_family), and this 
> code will fail to compile too.

the code i was porting did have an #ifdef case for BSDs already. (i know
that's not an ellegant sollution, but see below..)

> The portable solution is to not use 
> such initialization because you aren't sure what fields are in struct 
> sockaddr_un.
> 
> >- the non-GLIBC example should use strncpy
> 
> There is a question whether we should include _portability_ issues in 
> our _porting_ page.  If we do, then we have to include example using 
> strncpy.

oh please please. we shouldn't introduce portability problems but we
aren't the "corageous knights" who go around fixing others' bugs just
for the fun of it.

I'd like to put up a clear bug report for gcc, then replace the lines in
PortingIssues with an explanation on the gcc bug and that such code should
remain intact. If noone opposes, i'll go for it.

-- 
Robert Millan

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

Another world is possible - Just say no to genocide



Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>, glibc@packages.qa.debian.org:
Bug#187391; Package libc0.3-dev. Full text and rfc822 format available.

Acknowledgement sent to Robert Millan <zeratul2@wanadoo.es>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>, glibc@packages.qa.debian.org. Full text and rfc822 format available.

Message #134 received at 187391@bugs.debian.org (full text, mbox):

From: Robert Millan <zeratul2@wanadoo.es>
To: 187391@bugs.debian.org
Cc: bug-hurd@gnu.org, control@bugs.debian.org
Subject: bug found (in libc)
Date: Sat, 26 Apr 2003 19:30:01 +0200
tag 187391 patch
thanks

ok, by differing the bits/sockaddr.h from GNU and from
GNU/Linux it seems the final conclusion on this bug is:

the problem can be fixed by simply appliing this patch
to bits/sockaddr.h:

--- bits/sockaddr.h.old 2002-11-20 01:41:35.000000000 +0100
+++ bits/sockaddr.h     2003-04-26 14:52:38.000000000 +0200
@@ -33,7 +33,6 @@
    `struct sockaddr_in', `struct sockaddr_un', etc.  */
  
 #define        __SOCKADDR_COMMON(sa_prefix)    \
-  unsigned char sa_prefix##len;                \
   sa_family_t sa_prefix##family
  
 #define __SOCKADDR_COMMON_SIZE (2 * sizeof (unsigned char))


However, there are more differences between both versions:

--- /include/bits/sockaddr.h    2002-11-20 01:41:35.000000000 +0100
+++ /gli/usr/include/bits/sockaddr.h    2003-04-19 20:56:39.000000000 +0200
@@ -1,5 +1,5 @@
-/* Definition of `struct sockaddr_*' common members.  4.4 BSD version.
-   Copyright (C) 1995, 1996, 1997, 1998, 2001 Free Software Foundation, Inc.
+/* Definition of `struct sockaddr_*' common members.  Generic/4.2 BSD version.
+   Copyright (C) 1995,1996,1997,1998,2000,2001 Free Software Foundation, Inc.
    This file is part of the GNU C Library.
  
    The GNU C Library is free software; you can redistribute it and/or
@@ -26,18 +26,15 @@
  
  
 /* POSIX.1g specifies this type name for the `sa_family' member.  */
-typedef unsigned char sa_family_t;
+typedef unsigned short int sa_family_t;
  
 /* This macro is used to declare the initial common members
    of the data types used for socket addresses, `struct sockaddr',
    `struct sockaddr_in', `struct sockaddr_un', etc.  */
  
-#define        __SOCKADDR_COMMON(sa_prefix)    \
-  unsigned char sa_prefix##len;                \
+#define        __SOCKADDR_COMMON(sa_prefix) \
   sa_family_t sa_prefix##family
                                                                                
-#define __SOCKADDR_COMMON_SIZE (2 * sizeof (unsigned char))
-
-#define _HAVE_SA_LEN   1       /* We have the sa_len field.  */
+#define __SOCKADDR_COMMON_SIZE (sizeof (unsigned short int))
                                                                                
 #endif /* bits/sockaddr.h */

which indicate a disparity on what the POSIX 1003.1g standard
says. is sa_family_t an unsigned char or an unsigned short int?

you can fix this bug with the first diff. but someone should
take a look at POSIX.1g to find out which of short int or char
is the correct value.

-- 
Robert Millan

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

Another world is possible - Just say no to genocide



Tags added: patch Request was from Robert Millan <zeratul2@wanadoo.es> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>, glibc@packages.qa.debian.org:
Bug#187391; Package libc0.3-dev. Full text and rfc822 format available.

Acknowledgement sent to nisse@lysator.liu.se (Niels Möller):
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>, glibc@packages.qa.debian.org. Full text and rfc822 format available.

Message #141 received at 187391@bugs.debian.org (full text, mbox):

From: nisse@lysator.liu.se (Niels Möller)
To: Robert Millan <zeratul2@wanadoo.es>
Cc: 187391@bugs.debian.org, bug-hurd@gnu.org
Subject: Re: bug found (in libc)
Date: 26 Apr 2003 20:14:48 +0200
Robert Millan <zeratul2@wanadoo.es> writes:

> the problem can be fixed by simply appliing this patch
> to bits/sockaddr.h:

As we aim for binary compatibility with linux, I'm pretty sure we want
to use the same definition of struct sockaddr and sa_family_t as on
linux.

> which indicate a disparity on what the POSIX 1003.1g standard
> says. is sa_family_t an unsigned char or an unsigned short int?
> 
> you can fix this bug with the first diff. but someone should
> take a look at POSIX.1g to find out which of short int or char
> is the correct value.

I haven't read the posix documents, but I would be surprised if it
specifies the exact size of sa_family_t. Posix doesn't care about
binary compatibility, so I'd expect that all that matters for posix
compliance is that the type exists and is big enough for storing the
constant AF_INET and the other AF_* constants.

The entire point of standardizing types like sa_family_t is to allow
implementations to use any size they find convenient, and at the same
time make it possible to write portable source code.

/Niels

PS. I'm not all that familiar with the debian bug tracking system. I
left the "Cc: 187391@bugs.debian.org" in, but removed the "Cc:
control@bugs.debian.org". Let me know if I should have done
differently. 



Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>, glibc@packages.qa.debian.org:
Bug#187391; Package libc0.3-dev. Full text and rfc822 format available.

Acknowledgement sent to Robert Millan <zeratul2@wanadoo.es>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>, glibc@packages.qa.debian.org. Full text and rfc822 format available.

Message #146 received at 187391@bugs.debian.org (full text, mbox):

From: Robert Millan <zeratul2@wanadoo.es>
To: Niels Möller <nisse@lysator.liu.se>
Cc: 187391@bugs.debian.org, bug-hurd@gnu.org
Subject: Re: bug found (in libc)
Date: Sun, 27 Apr 2003 00:32:40 +0200
On Sat, Apr 26, 2003 at 08:14:48PM +0200, Niels Möller wrote:
> 
> I haven't read the posix documents, but I would be surprised if it
> specifies the exact size of sa_family_t. Posix doesn't care about
> binary compatibility, so I'd expect that all that matters for posix
> compliance is that the type exists and is big enough for storing the
> constant AF_INET and the other AF_* constants.

You mean POSIX.1g just says the size in bytes but doesn't
care wether they are chars or short ints?

> PS. I'm not all that familiar with the debian bug tracking system. I
> left the "Cc: 187391@bugs.debian.org" in, but removed the "Cc:
> control@bugs.debian.org". Let me know if I should have done
> differently. 

that's ok. control was there for adding the patch tag.

-- 
Robert Millan

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

Another world is possible - Just say no to genocide



Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>, glibc@packages.qa.debian.org:
Bug#187391; Package libc0.3-dev. Full text and rfc822 format available.

Acknowledgement sent to Roland McGrath <roland@gnu.org>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>, glibc@packages.qa.debian.org. Full text and rfc822 format available.

Message #151 received at 187391@bugs.debian.org (full text, mbox):

From: Roland McGrath <roland@gnu.org>
To: Robert Millan <zeratul2@wanadoo.es>
Cc: Niels Möller <nisse@lysator.liu.se>, 187391@bugs.debian.org, bug-hurd@gnu.org
Subject: Re: bug found (in libc)
Date: Sat, 26 Apr 2003 19:03:45 -0400 (EDT)
I don't know why you think there is a bug, but we don't plan to change the
sockaddr format any time soon.  sa_len is not a bug.



Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>, glibc@packages.qa.debian.org:
Bug#187391; Package libc0.3-dev. Full text and rfc822 format available.

Acknowledgement sent to nisse@lysator.liu.se (Niels Möller):
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>, glibc@packages.qa.debian.org. Full text and rfc822 format available.

Message #156 received at 187391@bugs.debian.org (full text, mbox):

From: nisse@lysator.liu.se (Niels Möller)
To: Roland McGrath <roland@gnu.org>
Cc: Robert Millan <zeratul2@wanadoo.es>, 187391@bugs.debian.org, bug-hurd@gnu.org
Subject: Re: bug found (in libc)
Date: 27 Apr 2003 10:37:48 +0200
Roland McGrath <roland@gnu.org> writes:

> I don't know why you think there is a bug, but we don't plan to change the
> sockaddr format any time soon.  sa_len is not a bug.

Do you plan on changing the definition on GNU/Linux, then? To me, it
seems obvious that using different definitions of struct sockaddr on
linux and hurd will make it impossible to run a socket application
binary on the hurd, if it's compiled for GNU/Linux, and vice versa.

Or have we dropped the plans for binary compatibility between
GNU/Linux and the hurd (when running on the same cpu)?

Regards,
/Niels



Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>, glibc@packages.qa.debian.org:
Bug#187391; Package libc0.3-dev. Full text and rfc822 format available.

Acknowledgement sent to Robert Millan <zeratul2@wanadoo.es>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>, glibc@packages.qa.debian.org. Full text and rfc822 format available.

Message #161 received at 187391@bugs.debian.org (full text, mbox):

From: Robert Millan <zeratul2@wanadoo.es>
To: Roland McGrath <roland@gnu.org>
Cc: 187391@bugs.debian.org, bug-hurd@gnu.org
Subject: Re: bug found (in libc)
Date: Sun, 27 Apr 2003 15:09:32 +0200
On Sat, Apr 26, 2003 at 07:03:45PM -0400, Roland McGrath wrote:
> I don't know why you think there is a bug, but we don't plan to change the
> sockaddr format any time soon.  sa_len is not a bug.

no no please, i'm not asking for a change in sockaddr format. the former
discussion went really off-topic, and we discussed stuff that had not
much to do with the actual bug.

let me rephrase the problem. the following code:

	#include <sys/socket.h>
	#include <sys/un.h>
	main ()
	{
	  sockaddr_un test = { AF_LOCAL, "" };
	}

which might be arguably nice or crap code, complies with the sockaddr_un
definition, but it will only compile on GNU/Linux. on GNU it fails
with:

	$ g++ -c test.c -o /dev/null
	test.c: In function `int main()':
	test.c:6: invalid conversion from `const char*' to `unsigned char'

and the bug can be fixed without changing the definition, by just
applying this:

--- bits/sockaddr.h.old 2002-11-20 01:41:35.000000000 +0100
+++ bits/sockaddr.h     2003-04-26 14:52:38.000000000 +0200
@@ -33,7 +33,6 @@
    `struct sockaddr_in', `struct sockaddr_un', etc.  */
  
 #define        __SOCKADDR_COMMON(sa_prefix)    \
-  unsigned char sa_prefix##len;                \
   sa_family_t sa_prefix##family
  
 #define __SOCKADDR_COMMON_SIZE (2 * sizeof (unsigned char))


-- 
Robert Millan

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

Another world is possible - Just say no to genocide



Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>, glibc@packages.qa.debian.org:
Bug#187391; Package libc0.3-dev. Full text and rfc822 format available.

Acknowledgement sent to Robert Millan <zeratul2@wanadoo.es>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>, glibc@packages.qa.debian.org. Full text and rfc822 format available.

Message #166 received at 187391@bugs.debian.org (full text, mbox):

From: Robert Millan <zeratul2@wanadoo.es>
To: Niels Möller <nisse@lysator.liu.se>
Cc: bug-hurd@gnu.org
Subject: Re: bug found (in libc)
Date: Sun, 27 Apr 2003 15:12:41 +0200
On Sun, Apr 27, 2003 at 10:37:48AM +0200, Niels Möller wrote:
> Roland McGrath <roland@gnu.org> writes:
> 
> > I don't know why you think there is a bug, but we don't plan to change the
> > sockaddr format any time soon.  sa_len is not a bug.
> 
> Do you plan on changing the definition on GNU/Linux, then? To me, it
> seems obvious that using different definitions of struct sockaddr on
> linux and hurd will make it impossible to run a socket application
> binary on the hurd, if it's compiled for GNU/Linux, and vice versa.
> 
> Or have we dropped the plans for binary compatibility between
> GNU/Linux and the hurd (when running on the same cpu)?

that's offtopic. i don't mind if you want to discuss wether we have
the goal of binary compatibilty, but please don't CC the bug log
in debian because it adds even more confusion to a bug that is
actualy realy simple.

-- 
Robert Millan

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

Another world is possible - Just say no to genocide



Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>, glibc@packages.qa.debian.org:
Bug#187391; Package libc0.3-dev. Full text and rfc822 format available.

Acknowledgement sent to nisse@lysator.liu.se (Niels Möller):
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>, glibc@packages.qa.debian.org. Full text and rfc822 format available.

Message #171 received at 187391@bugs.debian.org (full text, mbox):

From: nisse@lysator.liu.se (Niels Möller)
To: Robert Millan <zeratul2@wanadoo.es>
Cc: Roland McGrath <roland@gnu.org>, 187391@bugs.debian.org, bug-hurd@gnu.org
Subject: Re: bug found (in libc)
Date: 27 Apr 2003 15:55:25 +0200
Robert Millan <zeratul2@wanadoo.es> writes:

> no no please, i'm not asking for a change in sockaddr format.

[...]

> and the bug can be fixed without changing the definition, by just
> applying this:

[...]

>  #define        __SOCKADDR_COMMON(sa_prefix)    \
> -  unsigned char sa_prefix##len;                \
>    sa_family_t sa_prefix##family

But that *is* precisely a change of the sockaddr format. struct
sockaddr (and sockaddr_un, sockaddr_in, etc) are defined in terms of
__SOCKADDR_COMMON. For example,

<bits/socket.h>:

  /* Structure describing a generic socket address.  */
  struct sockaddr
    {
      __SOCKADDR_COMMON (sa_);	/* Common data: address family and length.  */
      char sa_data[14];		/* Address data.  */
    };

<sys/un.h>:

  /* Structure describing the address of an AF_LOCAL (aka AF_UNIX)
  socket.  */
  struct sockaddr_un
    {
      __SOCKADDR_COMMON (sun_);
      char sun_path[108];		/* Path name.  */
    };
  
Changing __SOCKADDR_COMMON changes the definition of all sockaddr*.
That's what that macro is for.

/Niels



Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>, glibc@packages.qa.debian.org:
Bug#187391; Package libc0.3-dev. Full text and rfc822 format available.

Acknowledgement sent to Roland McGrath <roland@frob.com>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>, glibc@packages.qa.debian.org. Full text and rfc822 format available.

Message #176 received at 187391@bugs.debian.org (full text, mbox):

From: Roland McGrath <roland@frob.com>
To: nisse@lysator.liu.se (Niels Möller)
Cc: Robert Millan <zeratul2@wanadoo.es>, 187391@bugs.debian.org, bug-hurd@gnu.org
Subject: Re: bug found (in libc)
Date: Sun, 27 Apr 2003 14:25:26 -0400 (EDT)
> Or have we dropped the plans for binary compatibility between
> GNU/Linux and the hurd (when running on the same cpu)?

This is the least of the things that will have to change before we can have
binary compatibility.



Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>, glibc@packages.qa.debian.org:
Bug#187391; Package libc0.3-dev. Full text and rfc822 format available.

Acknowledgement sent to Roland McGrath <roland@gnu.org>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>, glibc@packages.qa.debian.org. Full text and rfc822 format available.

Message #181 received at 187391@bugs.debian.org (full text, mbox):

From: Roland McGrath <roland@gnu.org>
To: Robert Millan <zeratul2@wanadoo.es>
Cc: 187391@bugs.debian.org, bug-hurd@gnu.org
Subject: Re: bug found (in libc)
Date: Sun, 27 Apr 2003 14:28:54 -0400 (EDT)
> let me rephrase the problem. the following code:
> 
> 	#include <sys/socket.h>
> 	#include <sys/un.h>
> 	main ()
> 	{
> 	  sockaddr_un test = { AF_LOCAL, "" };
> 	}

This code is wrong, i.e. not portable or POSIX-compliant.  You cannot use
normal initializers for a structure that is part of a standard API, because
in no such structure does the API specify the order of members, and in most
such structures it's permissible to have additional members.  You can use
an initializer if you use C99 labelled syntax, but what the code ought to
do is not use an initializer.

> and the bug can be fixed without changing the definition, by just
> applying this:

You seem to be confused.  That patch changes the definition of struct
sockaddr_*, and not in a way that is compatible with anything else.



Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>, glibc@packages.qa.debian.org:
Bug#187391; Package libc0.3-dev. Full text and rfc822 format available.

Acknowledgement sent to GOTO Masanori <gotom@debian.or.jp>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>, glibc@packages.qa.debian.org. Full text and rfc822 format available.

Message #186 received at 187391@bugs.debian.org (full text, mbox):

From: GOTO Masanori <gotom@debian.or.jp>
To: Roland McGrath <roland@gnu.org>, 187391@bugs.debian.org
Cc: Robert Millan <zeratul2@wanadoo.es>, bug-hurd@gnu.org
Subject: Re: Bug#187391: bug found (in libc)
Date: Mon, 28 Apr 2003 14:53:28 +0900
At Sun, 27 Apr 2003 14:28:54 -0400 (EDT),
Roland McGrath wrote:
> > let me rephrase the problem. the following code:
> > 
> > 	#include <sys/socket.h>
> > 	#include <sys/un.h>
> > 	main ()
> > 	{
> > 	  sockaddr_un test = { AF_LOCAL, "" };
> > 	}
> 
> This code is wrong, i.e. not portable or POSIX-compliant.  You cannot use
> normal initializers for a structure that is part of a standard API, because
> in no such structure does the API specify the order of members, and in most
> such structures it's permissible to have additional members.  You can use
> an initializer if you use C99 labelled syntax, but what the code ought to
> do is not use an initializer.
> 
> > and the bug can be fixed without changing the definition, by just
> > applying this:
> 
> You seem to be confused.  That patch changes the definition of struct
> sockaddr_*, and not in a way that is compatible with anything else.

That's right.

BTW, Roland, could you plan to add sun_len into sockaddr_un on Hurd?
It's not senseless modification, I think.

Regards,
-- gotom



Changed Bug submitter from Robert Millan <zeratul2@wanadoo.es> to Robert Millan <rmh@debian.org>. Request was from Robert Millan <rmh@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Changed Bug submitter from Robert Millan <rmh@debian.org> to Robert Millan <rmh@aybabtu.com>. Request was from Robert Millan <rmh@aybabtu.com> to control@bugs.debian.org. Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Sat Apr 19 02:56:52 2014; Machine Name: buxtehude.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.