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
testhash.patch
Description: Binary data
