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

Re: Bignums


> Note: I don't have any religious preference for either byte order.  But
> it's hard to see how "it does actually matter".
> 
> If you are talking about binary data, it will have to be word-aligned
> after receipt, regardless of whether it also has to be byte-swapped.
> (Unless you are suggesting that all bignum fields in the SPKI binary
> representation be 64-bit aligned, like IPv6.  That restriction would be
> a bit unusual for an application-layer data structure.)
> 
> If you are talking about hex data, you have to process the input 4 bits
> at a time, regardless of whether you store the binary result high-to-low
> or low-to-high.

If you are processing a string of indeterminate length from the first
digit your code will look like this.

LSB version:

i' = 0
reading = 0
WHILE reading
     a [bytesex_swap (i)]' = hex_to_num (string[i*2], string [i*2+1])
     reading = string[i*2+2] <> ' '
     i' = i + 1


MSB version:

i' = 0
reading = 0
WHILE reading
     temp [bytesex_swap (i)]' = hex_to_num (string[i*2], string [i*2+1])
     reading = string[i*2+2] <> ' '
     i' = i + 1
SEQ ii = 0 FOR i
     a [ii] = temp [i - ii]

The final fixup is required because you don't have the length of
the number in advance as you are reading.


Moral: LSB representation allows indefinite length numbers to be aligned
on arbitrary boundaries in a single pass. MSB requires two passes
whatever you do.


> Flip a coin, pick one, and move on.

No, LSB matters. If we want this in cell phones and other weany 8 bit 
processor devices we cannot afford to make ASN.1 type bloopers.

I believe that we should set being able to parse a cert using a single
pass without backspacing as an objective for the spec. IE the spec
must be capable of being parsed using a FSR without additional memory.


	Phill
Follow-Ups: References: