Re: iSCSI base64 and 12-92

[Bill Studenmund <wrstuden@wasabisystems.com>]

On Thu, 23 May 2002, Martins Krikis wrote:

To quote David, I think we're in violent agreement. :-)

> --- Bill Studenmund <wrstuden@wasabisystems.com>
> wrote:
>
> > On Thu, 23 May 2002, Julian Satran wrote:
> >
> > > If base 64 is neede for large integers there is no
> > good reason to test
> > > that it is not used for short integers.
> >
> > I respectfully disagree. base64 is awkward for
> > numbers, as it is not a
> > numerical encoding.
>
> Me too. Base64 should not be allowed for anything
> that's currently negotiable in the operational stage.
>
> > At least if the length of the
> > number (in octets) is
> > variable. 1, 2, 4, and 8 octet numbers are fine. But
> > 3, 5, 6, and 7 are
> > just plain gross. We have to load them into a
> > correspondingly larger data
> > type (32 or 64-bit unsigned int as appropriate), and
> > then mask off
> > unsent bytes. Oh, and if we're on an LE box, we then
> > have to byte-swap the
> > thing.
>
> That's not really the problem. For encoding a
> small number in base64, you byte-swap if necessary,
> pass the leading 0-bytes (if any), then run
> your regular base64 encoding that operates on strings.
> For decoding, you run the decoder (that operates
> on strings) first, count the resulting bytes,
> move it in your 32-bit or 64-bit register from the
> "right end", add 0-bytes (if necessary) on the
> left end and byteswap.

I think we're both agreeing it's cumbersome. :-)

> > Julo, have you actually coded a base64 decoder for
> > the small (less than
> > 2^64) ints we use in the protocol and verified its
> > correctness? I will
> > admit I haven't but that's because as I worked on
> > it, it got very gross.
> > And for no discernalbe benefit. Yes, we can do it.
> > But I'd rather put the
> > effort verifying this would take into making some
> > other part of the code
> > work well.
>
> A decoder is a decoder, it does work even
> on 0-length input. It works on strings, produces
> "binary strings". Putting the right number of
> 0-bytes to the left and byteswapping should not
> go in the decoder, it should be a separate thing,
> IMHO. But I also see no benefit in even allowing
> the small numbers to be given in any representation
> that cannot be thrown at strtoul() as is.

Oh, I was talking about the whole thing, the decoder that takes base64 &
returns a #. That's the base64 decoder chained with the code to turn the
result into a number.

[violent agreement snipped :-) ]

Take care,

Bill