(Regarding <code>uint8_t c[] = {'0x01', '0x02'};</code> saved to a file and retrieved:)
> Regardless of how that file is stored on the stick if I load that file back into memory at address a (using an appropriate c function) then on a little endian machine the bit pattern in a and a+1 will be<code>
10000000 010000000
</code> and on a big endian machine<code>
00000001 00000010
</code>
For this discussion, and certainly for thinking about these issues, it is necessary to distinguish how we refer to bits from how they exist in the hardware. The confusion exhibited in the above quote is, in part, due to conflating representations.
If, after the above file save operation, byte array c[] is read back, from the file, (on any system made and/or used by sane people), then the following C code will print "Bits survive to/from file round trip!"<code>
if (c[0] == '0x01' && c[1] == '0x02')
printf("%s\n", "Bits survive to/from file round trip!");
</code> And if we (the sane) are going to speak of binary representations in text, using the undisputed convention that digits of lesser significance appear to the right of digits of greater significance, we will agree that 00000001 is the correct binary written form of the value we know as 0x01 or 1, and that 00000010 is the correct binary written form of the value we know as 0x02 or 2.
As someone who has looked at the architecture-dependent and platform-dependent parts of the SQLite3 code, I can warrant that nothing there is concerned with straightening out bit order mix-ups that might be suspected to arise from cross-platform database transfers.
The whole concern with bit-order is misplaced, and anybody (on SO or anywhere else) who helped cement or magnify that worry needs a good talking-to. It is a non-problem, best solved by reorganizing the thinking that produced the worry.
(Later edit:) I'm not saying that the worry is insane. It would be possible to (mis)design, then build some hardware where the worry (or nightmare) would be matched by real-world events. The most likely outcome of that build would be great embarrassment by the hardware designer(s) responsible for the error, soon followed by some rewiring (if possible) and redesign. Possibly, the hardware designer(s) would say "That's how we want it to work. The users must adapt!", in which case they would soon be fired from any organization that is not doomed to quick failure. If such hardware was offered for sale, it would be scorned and ridiculed, and would not be in common use or supported by any common operating system or other software. In other words, it **will not happen** in the semi-sane world we have today.