On Tue, Mar 26, 2024 at 7:25 PM Dmitry Goncharov <dgoncha...@users.sf.net> wrote:
> Thank you for a quick response, Greg. > > On Tue, Mar 26, 2024 at 4:56 PM Greg McGary <greg.mcg...@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
