Subject: Re: bug#25629: Hrm, actually autom4te isnt part of automake, but rather autoconf.

From: demerphq <[email-masked]>
Date: Sun, 16 Jul 2017 12:02:12 +0200

On 16 Jul 2017 01:50, "Mathieu Lirzin" <[email-masked]> wrote:

Hello Yves,

demerphq <[email-masked]> writes:

> Also I observe that there were previous patches to ensure most uses of
> keys() were sorted. However not all of them, including diagnostics,
> and various other places where the key order could be exposed to a
> user.
>
> Attached is a patch that I believe fixes any remaining uses of unsorted
keys.
>
> I took the policy that automake is not performance sensitive, at least
> at the level of sorting keys, and that sorting something that is not
> strictly necessary does no harm.
>
> I admit I have not been able to properly test all of these changes,
> but superficial testing does not reveal any issues.
>
> Anyway, sorry for the misleading original bug-report.
>
> Cheers,
> Yves

Can you explain what would be the benefit for Automake to have such
deterministic behavior?

Thanks for the report.

The most obvious reason is when debugging with something like diff
deterministic behaviour eliminates spurious changes. Also having a
deterministic and well understood ordering rule eliminates any concern that
order might matter, and that a bug or whatnot was due to a different order
(regardless of whether such a concern actually makes sense.) also sorting
output lists makes them more readable.  I don't know how well tested
Automake is but I would assume deterministic hash order would help there
too.

Also note that Prior to hash randomization the key order would have been
consistent between multiple runs. Thus when randomization was introduced
the behaviour of Automake changed and effectively regressed. Sorting keys
effectively restores the original behaviour.

Cheers
Yves