[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
Re: libc0.3-dev: weirdness with sockaddr_un, Niels Möller, 2003/04/03