SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    Re: iSCSI base64 and 12-92



    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
    
    


Home

Last updated: Thu May 23 23:18:32 2002
10291 messages in chronological order