Re: uint64

["Joseph Galbraith" <galb-list%vandyke.com@localhost>]

> draft-ietf-secsh-architecture-07.txt defines the type uint64,
> 
>     uint64
>       Represents a 64-bit unsigned integer.  Stored as eight bytes in
>       the order of decreasing significance (network byte order).
> 
> It is currently used only from by the filexfer document, for file
> sizes, offsets and the like.
> 
> I'd like to ask if we really need this type. The alternative is to use
> mpint (or mpuint, if that is added) for any numbers that can be
> expected to grow larger than an uint32.
> 
> All implementations can be expected to have a native uint32 and a
> bignum type. They may or may not have an 64 bit integer type. By using
> mpint, the protocol stays agnostic. An implementation will convert the
> mpint value to its natural offset type (be that 32 bit, 64 bit, or
> whatever), or return an appropriate error message if the number is too
> big.

I think mpint would be a mistake.

This would be a new requirement for the sftp subsystem,
which currently does not require a bignum library to
implement.

An architecture that doesn't natively support 64
bit integer types probably doesn't have 64 bit
API's to pass the number into, or such interfaces
are probably something like uint32 highPart,
uint32 lowPart.

Regardless, such an implementation should treat
a uint64 as

  uint32 highPart
  uint32 lowPart

and fail the operation if highPart != 0 and it
can't support it.

This is a simple solution that doesn't require
the addition of another large, complicated
library to the sftp subsystem.

It wouldn't bother me if we wanted to strike
uint64 and simply use

  uint32 highPart
  uint32 lowPart

This is actually the way I have to have the data
anyway, since that is how the Win32 file-system
calls are done.

But, having uint64 doesn't really bother me either,
and is, perhaps, conceptually cleaner.

- Joseph