Robert Millan <[EMAIL PROTECTED]> writes:
> note what the docs say in reference to `char sun_path[108]':
>
> *Incomplete:* Why is 108 a magic number? RMS suggests making
> this a zero-length array and tweaking the following example
> to use `alloca' to allocate an
On Thu, Apr 03, 2003 at 06:02:12AM -0800, Jeff Bailey wrote:
> On Thu, Apr 03, 2003 at 08:29:43PM +0900, GOTO Masanori wrote:
>
> > BTW, I don't know why Hurd uses the generic definition. If it's not
> > intentional, we can say it's a bug.
>
> Or should the generic definition be changed? I'll a
On Thu, Apr 03, 2003 at 08:29:43PM +0900, GOTO Masanori wrote:
> BTW, I don't know why Hurd uses the generic definition. If it's not
> intentional, we can say it's a bug.
Or should the generic definition be changed? I'll add it to my TODO
list to look at.
--
Are you going to stay vegeterian?
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
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 vi
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 fr
At Thu, 3 Apr 2003 03:42:11 +0200,
Robert Millan wrote:
> the following code seems to be compliant with the Glibc documentation
> referred to sockaddr_un, as it provides a char* as the second component
> of the struct:
>
> #include
> #include
> main ()
> {
> sockaddr_un test = { AF_L
