3 ms·

> Some merely use spaces to separate bytes visually, others actually group the bytes and parse them as integers, swapping them as needed to read like human writ

> Some merely use spaces to separate bytes visually, others actually group the bytes and parse them as integers, swapping them as needed to read like human writing. In other words, your problem is that your hex editor is incorrectly assuming that the numbers are little-endian. If it interpreted them as big-endian then nothing would be swapped since the order of the bytes matches the standard conventions for numbers in most European writing systems. This is not a big-endian problem, it's a little-endian problem. A decent hex editor will allow you to set the byte order to match your file. (And as the article points out, the issue would be reversed if the bytes were displayed right-to-left following the same conventions that we use for numbers… but then all your strings would be reversed.) Both representations have strengths and weaknesses depending on what you want to do. Most arbitrary-precision math works better with LE. On the other hand, hexadecimal string formatting works better with the BE encoding, where LE would require either the input or output to be reversed.

dataflow 5y ago
No, this has nothing to do with the editor or bignums. I'm just using those to illustrate the underlying inconsistency. The most natural order/sequence out there is that of natural numbers with zero (aka whole numbers), i.e. N0 = 0, 1, 2, 3, ... So I'm basically arguing that means the most digit places are in the same order, i.e. the coefficients would be ordered as 256^N i.e. 256^0, 256^1, 256^2, 256^3, ...
- nybble41 5y ago
  I was addressing your first point about how the data is displayed in hex editors. But the rest IMHO is just fixating on one particular operation ("multiplying by 256" by prepending bytes without regard for the data format) which does not seem particularly useful or prudent. Sure, in LE you can prepend a 00 byte to multiply by 256. In BE you do the same by appending a 00 byte at the end, and a 00 at the beginning would just be extra padding, exactly like adding a 0 at the start or end of a decimal number (which are also typically written in big-endian notation). In either case you need to allow for the change in the overall length or risk losing data and probably corrupting the rest of the data file in the process. If your data is actually groups of 16-bit or 32-bit elements rather than bytes then you need to add a whole number of elements for this to make any sense at all, regardless of byte order. You can't have an arbitrary-precision integer consisting of 5½ elements. Removing a byte from the end to preserve the length corresponds to reducing module 256^N in LE notation or dividing by 256 in BE; which is "more natural" would depend on the context. For most arbitrary-precision math operations LE is easier to work with. The only thing making BE more "natural" in some situations (in particular, reading numbers out of a byte-oriented hex listing) is the historical accident that we borrowed our number system from right-to-left languages, where they were written little-endian with the one's place on the right, without reversing the order to match the surrounding text. Which leads to the alignment issues highlighted in the article.

dataflow 5y ago

No, this has nothing to do with the editor or bignums. I'm just using those to illustrate the underlying inconsistency. The most natural order/sequence out there is that of natural numbers with zero (aka whole numbers), i.e. N0 = 0, 1, 2, 3, ... So I'm basically arguing that means the most digit places are in the same order, i.e. the coefficients would be ordered as 256^N i.e. 256^0, 256^1, 256^2, 256^3, ...

nybble41 5y ago
I was addressing your first point about how the data is displayed in hex editors. But the rest IMHO is just fixating on one particular operation ("multiplying by 256" by prepending bytes without regard for the data format) which does not seem particularly useful or prudent. Sure, in LE you can prepend a 00 byte to multiply by 256. In BE you do the same by appending a 00 byte at the end, and a 00 at the beginning would just be extra padding, exactly like adding a 0 at the start or end of a decimal number (which are also typically written in big-endian notation). In either case you need to allow for the change in the overall length or risk losing data and probably corrupting the rest of the data file in the process. If your data is actually groups of 16-bit or 32-bit elements rather than bytes then you need to add a whole number of elements for this to make any sense at all, regardless of byte order. You can't have an arbitrary-precision integer consisting of 5½ elements. Removing a byte from the end to preserve the length corresponds to reducing module 256^N in LE notation or dividing by 256 in BE; which is "more natural" would depend on the context. For most arbitrary-precision math operations LE is easier to work with. The only thing making BE more "natural" in some situations (in particular, reading numbers out of a byte-oriented hex listing) is the historical accident that we borrowed our number system from right-to-left languages, where they were written little-endian with the one's place on the right, without reversing the order to match the surrounding text. Which leads to the alignment issues highlighted in the article.