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: GOTO Masanori
Subject: Re: Bug#187391: libc0.3-dev: weirdness with sockaddr_un
Date: Thu, 03 Apr 2003 20:29:43 +0900
User-agent: Wanderlust/2.9.9 (Unchained Melody) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (Unebigoryōmae) APEL/10.3 Emacs/21.2 (i386-debian-linux-gnu) MULE/5.0 (SAKAKI)

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




reply via email to

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