dillon at apollo.backplane.com
Sat Apr 29 12:47:43 PDT 2006
:On Wed, Apr 26, 2006 at 09:52:38AM -0700, Matthew Dillon wrote:
:> In particular, as we shift to 64 bit integers, we really want to use
:> signed 64 bit integers rather than unsigned 64 bit integers. Negative
:> numbers are used for all sorts of special cases.
:In that case define a global upper limit for valid offsets and use
:number above that for the special cases. Just the number of checks for
:negative offsets and overlarge offsets would be simplified. Beside, if
:you insist on keeping it signed, make it ssize_t.
The problem here is that this is used all over the internals of the
operating system. It makes no sense to obfuscate code that would
otherwise be clearly readable by using 'ssize_t' instead of 'int'
when half the code in question has severe limitations on the data
size being represented anyhow.
For example, when a UIO is translated into buffer cache ops, a code
loop is taking the UIO/IOV lengths and doing calculations to produce
BUFfer cache sizes, which are far more limited and clearly should not
be using ssize_t.
I am not going to create a mess of code casting size_t or ssize_t to
int or vise-versa for the half dozen (or more) places in the code
where such translations take place. Even if we were to do that, basic
assumptions have to be made on what 'ssize_t' actually is for the casts
to do what is expected... effectively, it MUST be an int anyway or
the code blows up. Because of that, it's really awefully silly to
try to abstract the kernel code internally when 'int' works perfectly
So, no, we are not going on a size_t/ssize_t binge just because some
idiot 25 years ago decided to abstract out simple length fields in
system call specifications that should never have been abstracted out,
and decided to use unsigned quantities in order to address 65536 bytes
instead of 32768 bytes in some ancient 16 bit cpu decades ago. It
was a huge mistake to use anything other then 'int' for system calls
like read() and write(). Hell, just look at how the system call for
read() is prototypes:
ssize_t read(int d, void *buf, size_t nbytes)
How stupid is that? It takes an unsigned argument, is supposed to
return the number of bytes read, but returns a signed argument, and
'-1', which is an inband value for a valid unsigned 0xffffffff,
indicates an error.
We are not repeating that mess inside the kernel.
<dillon at xxxxxxxxxxxxx>
More information about the Kernel