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: Stephan Trebels
Subject: Re: Bug#187391: libc0.3-dev: weirdness with sockaddr_un
Date: 03 Apr 2003 13:31:42 +0200

Is it actually specified which type sun_len has (as unsigned char of
course limits to 255 bytes length of the path itself)?  

I'd have thought the "Hurd" version for internal stuff would be
something like 
  sa_family_t sun_family;
  unsigned int sun_len;
  char sun_len[0];
Which would probably violate all standards but remove the arbitrary
limit in the path name...  This seems to mean, that a path can never be
longer, otherwise.

Just a question, Stephan

On Thu, 2003-04-03 at 13:29, GOTO Masanori wrote:
> 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
> 
> 
> _______________________________________________
> Bug-hurd mailing list
> Bug-hurd@gnu.org
> http://mail.gnu.org/mailman/listinfo/bug-hurd
-- 
        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






reply via email to

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