ext/dba/tests/dba_gdbm.phpt: test failure due to key ordering

[orlitzky]

Description

Original report: https://bugs.gentoo.org/935379

The diff for this failed tests contains e.g.

-key4: Another Content String
 key2: Content String 2
 key5: The last content string
-[key10]name10: Content String 10
 name9: Content String 9
+[key10]name10: Content String 10
+key4: Another Content String
 [key30]name30: Content String 30
 Total keys: 6

The corresponding test code is,

// Fetch data                                                               
$key = dba_firstkey($db_writer);
$total_keys = 0;
while ($key) {
    echo $key, ': ', dba_fetch($key, $db_writer), \PHP_EOL;
    $key = dba_nextkey($db_writer);
    $total_keys++;
}
echo 'Total keys: ', $total_keys, \PHP_EOL;

So to me it looks like the insert order is not guaranteed to be the iteration order according to dba_firstkey() and dba_nextkey(). Since there are only six keys, I guess we could sort the output (in a locale-independent way) before printing it?

PHP Version

PHP-8.2.20

Operating System

Gentoo Linux

[Girgias]

This might actually something that changed in the GDBM driver/lib? As I don't see why it would change randomly, I had consistent behaviour when I was actively refactoring this a while back

[orlitzky]

It's possible but my first guess would be that it's on x86. The same version with the same build flags passes for me on amd64.

[orlitzky]

The iteration order is apparently based on gdbm's internal hashes and FWIW gdbm's own test suite sorts the output, see e.g. https://git.savannah.gnu.org/cgit/gdbm.git/tree/tests/create00.at

The gtdump utility is a little CLI program that uses firstkey() and nextkey().

[Girgias]

Right, then adding a sort and referencing the upstream test makes sense.