Thank you for a quick response, Greg.
On Tue, Mar 26, 2024 at 4:56 PM Greg McGary <greg.mcgary@gmail.com> wrote:
> The code makes no effort to be endian-independent because it is written
> for in-memory hashing on a uniprocessor or homogeneous multiprocessor.
Do you know of a specific difficulty of making that hashing endian-independent?
No real difficulty--just some trivial extra code & overhead to swap bytes.
> Why do the hash keys and table layout need to be consistent across
> heterogeneous architectures?
In the gnu make there were occurrences when a change was introduced,
along with a unit test, and tested on little endian.
Later, someone would run the test on big endian and find out that the
test fails, because the test expects make to do something (e.g. remove
temporary files or print targets) in a certain order, and on big
endian the order turns out to be different due to hashing.
We'd then fix the test some way or another, until another occurrence.
So, in the end hashing works well in gnu make. This difference just
introduces unnecessary maintenance work.
This all makes sense. The hash values are exposed indirectly, and the values
matter for unit tests. Thanks for explaining!
G