Subject: uint64

From: [email-masked] (Niels M�ller)
Date: 29 Mar 2001 16:08:29 +0200

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.

/Niels

---

From: "Joseph Galbraith" <[email-masked]>
Date: Fri, 30 Mar 2001 07:14:13 -0700

> whatever), or return an appropriate error message if the number is too

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

---

From: Markus Friedl <[email-masked]>
Date: Fri, 30 Mar 2001 16:16:57 +0200

> I think mpint would be a mistake.

I agree with Joseph, the sftp subsystem should not depend
on bignum libraries.

Early versions of OpenSSH's sftp-server used the approach

> and fail the operation if highPart != 0 and it

-markus

---

From: [email-masked] (Niels M�ller)
Date: 30 Mar 2001 16:32:02 +0200

> which currently does not require a bignum library to

You don't need a full bignum library just because you use the mpint
representation.

I'm imagining a decoding function that's somthing like

  off_t get_offset(input_buffer *b)
  {
    uint32_t length = get_uint32(b);
    uint32_t i;
    off_t offset;

    if (length > sizeof(off_t))
      /* Fail, preferably in some more graceful way */
      fatal();

    for (offset = 0, i = 0; i<length; i++)
      offset = (offset << 8) | get_uint8(i);
  
    return offset;
  }

Ok, I know that code is not quite correct (it would be if we had
mpuint rather than mpint), but I hope you get the idea.

With uint64, it seems I need explicit #ifdefs in order to handle
systems with different sizes of off_t.

So I believe that deleting uint64 would make the spec cleaner, and
without adding extra complexity to the implementation.

/Niels