bug-hurd
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]