PATCH: apr/test/testhash.c returning errors due to incorrectly assuming hashes are ordered

[David Jones <os...@gmail.com>]

apr/test/testhash.c is broken on EBCDIC platforms at a minimum.

But these existing testhash.c comments indicate an underlying problem:
          /* I don't know why these are out of order, but they are. I would
probably
           * consider this a bug, but others should comment.
           */


afaik, the hash iterator functions do not promise/attempt any ordering.
Some of the bits for the hash are thrown away when deciding which array
index to use to reference the hash entry.  You may have a few close strings
returned in their natural order by the hash iterator, but the next string
in order could have a hash value which is enough higher that, after
throwing away some bits, it maps to a lower array index.  Example: In one
of the tests, the element with key "hash5" is returned before the elements
with keys "hash1" through "hash4".

When testing on EBCDIC the order returned is different then on ASCII due to
the
different numerical values for characters, so code asis returns failures.

Appended is a patch that now alphabetically qsorts all the dumped hashes
using strcmp.
Each "Key abc Value xyz" string is placed into its own array element,
instead of concatenated
into 1 long string.
The calling routine can now assume an ordering knowing that dump_hash has
qsorted them,
and therefore verify that each key is stored once and only once.

Patch tests successfully on zOS and linux, at 2.2.6 and at trunk with
intersecting revision 442588 included