Re: [PATCH 0/2] Make ISO file output more reproducible

[Thomas Schmitt]

Hi,

the patches are applied now with some change, mostly minor ones.

Patch [1/2]:
  https://dev.lovelyhq.com/libburnia/libisofs/commit/3a43995

Patch [2/2]:
  https://dev.lovelyhq.com/libburnia/libisofs/commit/8d9fcf6

Please test whether your use cases still work with these changed changes.

------------------------------------------------------------------------
Deviations from the patches:

I had to modify the change to cmp_by_weight() to return 0 if both
values of {gf}->taken are equal. This can normally only happen if
f == g and then it is essential for cmp_by_weight() being a proper
ordering criterium according to man qsort:
  "The comparison function must return an integer [...] equal to
   [...] zero if the first argument is considered to be [...]
   equal to [...] the second."
A caller of the function is entiteled to expect that two identical
arguments are considered equal to each other, rather than to mutually
claim that they are greater than the other.
I think that not fulfilling this expectation opens a new opportunity
of "undefined" ordering or even unjustificable mistakes by qsort().
The burden to avoid equality of non-identical IsoFileSrc objects has
to be carried by ecma119_filesrc_array() and hidden_filesrc_array().

I changed style details of the new function cmp_node_name_tiebreak()
because of this compiler warning:
  ISO C90 forbids mixed declarations and code [-Wpedantic]
which was caused by declations of "f" and "g" after "if (cmp)".

The declaration of "cmp" in filesrc.c:cmp_by_weight() did not cause
warnings. Nevertheless i separated declaration and computation for
reasons of personal taste.

I slightly enlarged the comment in filesrc.h.

Both commit messages were shortened to my possibly outdated style.

------------------------------------------------------------------------

To answer the question whether the array indice used in patch [2/2] are
reproducible on all systems: Yes, they are.

Digging in code and 17 year old memories i found out that the file tree
model is at any time sorted alphabetically by the Rock Ridge file names,
which are unique in their respective directories and never get mangled.
The IsoFileSrc array of the emerging filesystem image is filled by a
traversal of the file tree model. I.e. it the sequence follows the
alphabetical sorting order of file names and thus is independent of the
history how the file nodes got into the tree.

In the light of these findings, i omitted the aspect of "[differences in]
filesystem ordering" from the commit message of patch [1/2].


Have a nice day :)

Thomas