|
![](/i/fill.gif) |
Invisible schrieb:
>>> When you read data from a first, you read the first byte first, and
>>> the last byte last. Therefore, the first byte should be the MSB.
>>
>> Seriously: Why? Just because us Westerners writing numbers this way
>> round?
>
> Because the most significant digit is the most important piece of
> information. It's "most significant".
Right. And in rhethorics they teach to leave the most important argument
for the end ("last but not least"). So?
It's not that I don't see those arguments. But they're not compelling
enough to declare big-endian "right" and little-endian "wrong". You may
call one of them "more intuitive [for us Westerners]", but that's as far
as it gets.
> Erm, NO.
>
> This happens because most cryptosystems are (IMHO incorrectly) specified
> to *not* use big-endian encoding.
Whatever: My point is that the fault is not in the little-endians, nor
in the big-endians, but just an inevitable consequence of the existence
of both, and the fault can be assigned to either side for not having
"given in".
> This means that if I want to implement such a system, I have to waste
> time and effort turning all the numbers backwards before I can process
> them, and turning them back the right way around again afterwards. It
> also means that when a paper says 0x3847275F, I can't tell whether they
> actually mean 3847275F hex, or whether they really mean 5F274738 hex,
> which is a completely different number.
0x3847275F is, in any case, 3847275F hex - although you'll indeed need
to know the endianness to tell whether it is 38;47;27;5F or 5F;27;47;38.
If some paper doesn't answer this question while it is of any relevance,
it is a bad paper.
>> Wouldn't it be more convenient to start with the least significant
>> digit, and stop the transmission once you have transmitted the most
>> significant nonzero digit? If you did that the other way round, you'd
>> have no way to know how long the number will be, and won't be able to
>> determine the actual value of each individual digit until after the
>> transmission.
>
> If you start from the least digit, you *still* can't determine the final
> size of the number until all digits are received.
But you can already store the digits at their final position if you know
the /maximum/ size. If you do it the other way round, you'll need to
shift the whole thing after the transmission if the maximum size is not
used.
Post a reply to this message
|
![](/i/fill.gif) |