To use big endian on real-world systems. And one of the reasons to use big endian is because diversity helps to find bugs in code. A bug that might result in a hidden off-by-one on little endian might crash on big endian.
Wouldn't that only matter if the bug has no affect on little endian?
Otherwise you don't need the other endian to confirm it?
Or are you saying to test their software before it goes out to big endian devices, which doesn't answer the question as to why someone would want to use it on those end devices?
> Wouldn't that only matter if the bug has no affect on little endian?
I don't know whether this logic applies to this specific sort of bug, but there is a long history of bugs that "don't matter" combining with other bugs to become something that matters. Therac-25 was a bug that didn't matter on the hardware it was developed for, but then the software that "worked fine" got repurposed for another hardware platform and people died. If there's an easy way to identify an entire class of bugs it seems like a good idea to do it.
