Fix GH-9296: incorrect ksort(..., SORT_REGULAR) behaviour on arrays with numeric and string keys

[DrDet]

The comparator function used at ksort or krsort in SORT_REGULAR mode need to be consistent with basic comparison rules.
These rules were changed in PHP-8.0 for numeric strings, but comparator used at ksort mistakenly kept the old behaviour.
It leads to inconsistent situations, when after ksort the first key is GREATER than some of the next ones by according to the basic comparison operators.

Simple example:

<?php

$array = ["600" => 0, "aaa" => 1];
ksort($array, SORT_REGULAR);
var_dump($array);
var_dump(array_key_first($array) <=> array_key_last($array));

In php7.4 we get:

array(2) {
  ["aaa"]=>
  int(1)
  [600]=>
  int(0)
}
int(-1)

That's OK, because it's consistent with php7.4 comparison rules.

In php8.0 the output is:

array(2) {
  ["aaa"]=>
  int(1)
  [600]=>
  int(0)
}
int(1)

Which is not OK, because it is not consistent with new php8.0 comparison rules.

After this fix the output is:

array(2) {
  [600]=>
  int(0)
  ["aaa"]=>
  int(1)
}
int(-1)

Which is consistent with php8.0 comparison rules.

See #9296

[cmb69]

Ugh! I'm pretty confused that this apparently has not been reported before.

[dstogov]

I think this is a bug and it's better to report it at https://github.com/php/php-src/issues

I would prefer, to keep the old (optimized) comparison code at least for numeric+numeric and string+string keys, and fallback to zend_compare() only for rare numeric+string and string+numeric cases.

It would be also great to have a separate test case with a reference to the issue report.

[DrDet]

I think this is a bug and it's better to report it at https://github.com/php/php-src/issues

Done with the bug report, see #9296

I would prefer, to keep the old (optimized) comparison code at least for numeric+numeric and string+string keys, and fallback to zend_compare() only for rare numeric+string and string+numeric cases.

Fixed at aa125c8

It would be also great to have a separate test case with a reference to the issue report.

Added at 23fc6d4

[dstogov]

Now this looks fine.

[cmb69]

Thank you!