Follow-up Comment #5, bug #65438 (group make):
> Regarding the hashing vs. endianness, I don't know.
What do you think of changing hashing to produce the same result on little and
big endian?
> Regarding sorting, doesn't this basically mean just using strcmp (or a
small
> wrapper around it) as the sorting function?
strcmp directly cannot be used, because the qsort comparison routine takes
pointers to struct file.
The impl in the attached patch contains function filecmp. filecmp can be
reduced to
static int
filecmp (const void *slotx, const void *sloty)
{
const struct file *x = *(const struct file **) slotx;
const struct file *y = *(const struct file **) sloty;
return strcmp (x->name, y->name);
}
> For justification I don't know that we really need one; if it's useful to
us
> to sort, we should sort even if users won't find it useful. Someone
looking
> at the output by hand may find it useful although it seems just as likely
they
> will run the output through sort themselves if they want it sorted.
Moreover make should not reimplement all the abilities of gnu sort (for
example).
On the other hand, the user won't be able to produce the output in the order
proposed in the patch, unless make produces it.
> It's too bad we don't have a simple way to sort the output in the test
> framework. It will be annoying if we choose "good" filenames and the test
> passes, but then we switch our hashing around and it breaks again.
i was thinking of the fact most users run and test make on little endian. This
results in occasional breakage like this one.
As long as there is this difference in hashing, such breakage is likely to
recur.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?65438>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
