netdev
[Top] [All Lists]

Re: socklen_t instead of size_t in struct cmsghdr

To: kuznet@xxxxxxxxxxxxx
Subject: Re: socklen_t instead of size_t in struct cmsghdr
From: Jakub Jelinek <jakub@xxxxxxxxxx>
Date: Mon, 2 Oct 2000 21:52:22 +0200
Cc: davem@xxxxxxxxxx, ak@xxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <200010021638.UAA24172@ms2.inr.ac.ru>; from kuznet@ms2.inr.ac.ru on Mon, Oct 02, 2000 at 08:38:57PM +0400
References: <20001002120349.L9588@sunsite.ms.mff.cuni.cz> <200010021638.UAA24172@ms2.inr.ac.ru>
Reply-to: Jakub Jelinek <jakub@xxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx
On Mon, Oct 02, 2000 at 08:38:57PM +0400, kuznet@xxxxxxxxxxxxx wrote:
> Hello!
> 
> > Would it be possible to change
> 
> Shit! The same story is with all the struct msghdr.

msghdr is not that severe (at least from the 32<->64 bit translation point
of view, because it has to be translated anyways (it contains pointers)), so
in msghdr I'd think it would be worth just to change msg_controllen to int
(aka socklen_t, because kernel apparently has no socklen_t type), msg_iovlen
is completely unrelated and as it sits between 2 64bit pointers, using 64bit
value in between looks like a good idea. If I look at Solaris msghdr (the
only non-Linux system I can look at headers ATM), iovlen is int and
controllen is socklen_t.

> 
> > Sparc 64bit userland can definitely survive that change,
> 
> Then change it. Only together with msghdr. Types of msg_namelen,

namelen is already an int, so just controllen and cmsg_len remains.

> msg_controllen and cmsg_len must coincide and be socklen_t.
> Changing only cmsg_len you will create real mess.
> If your statement about recompilation for glibc2.2 is truth
> (I suspect it is not yet 8)), it is not more harmful.
> 
> BTW, I have seen several days ago in a russian newsgroup
> stormy discussion. The people argue that "Sparc 64bit userland"
> simply does not exist. 8)8) Imagine, people using redhat, are _sure_,
> that linux is not able to run 64bit applications, even not saying about
> compilation and preparing 64bit binaries. 8)8)

Well, Sparc 64bit userland exists for years, though especially because of
the massive ABI changes during the years (last major ABI changes because
Solaris cannot follow their own ABI has been done about a month ago) and
because of lack of time for it on my and DaveM's part it is not part of any
distributions yet (but it should change very soon).
But the compiler I use for all SPARC compilations is already 64bit ;) :

$ ldd `which gcc`
libc.so.6 => /lib64/libc.so.6 (0xfffff80000120000)
/lib64/ld-linux.so.2 => /lib64/ld-linux.so.2 (0xfffff80000000000)
$ gcc -v
Reading specs from /usr/lib/gcc-lib/sparc64-redhat-linux/2.96/specs
gcc version 2.96 20000731 (Red Hat Linux 7.0)

        Jakub

<Prev in Thread] Current Thread [Next in Thread>