[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bug#187391: libc0.3-dev: weirdness with sockaddr_un
From: |
Robert Millan |
Subject: |
Re: Bug#187391: libc0.3-dev: weirdness with sockaddr_un |
Date: |
Thu, 3 Apr 2003 14:06:43 +0200 |
User-agent: |
Mutt/1.5.3i |
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
Re: libc0.3-dev: weirdness with sockaddr_un, Niels Möller, 2003/04/03