PATCH preadv/pwritev

[Matthew Dillon]

: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.
:
:Joerg

    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
    well.

    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.

					-Matt
					Matthew Dillon 
					<dillon at xxxxxxxxxxxxx>