ID: 40616 Updated by: [EMAIL PROTECTED] Reported By: phpbugs at jessemccarthy dot net -Status: Open +Status: Feedback Bug Type: Arrays related Operating System: Linux PHP Version: 5.2.1 New Comment:
>The reproduce code is too long? Yes, please remove everything not related to your problem. >The descriptions of actual and expected output are not >sufficient? Descriptions? No, descriptions are not enough, we need the results, not their descriptions. Previous Comments: ------------------------------------------------------------------------ [2007-02-23 23:30:33] phpbugs at jessemccarthy dot net Thanks for your quick response. The reproduce code is too long? The descriptions of actual and expected output are not sufficient? ------------------------------------------------------------------------ [2007-02-23 23:20:42] [EMAIL PROTECTED] And don't forget actual and expected output. ------------------------------------------------------------------------ [2007-02-23 23:19:04] [EMAIL PROTECTED] Please provide a SHORT but complete reproduce code, so we won't have to debug it. ------------------------------------------------------------------------ [2007-02-23 23:13:39] phpbugs at jessemccarthy dot net Description: ------------ I spent hours investigating why my script using uasort() was not producing the expected results before finally discovering that the problem is due to a bug / limitation in the uasort() implementation. I don't know what's actually happening in the source code, but my theory about the problem is that uasort() (or whatever underlying code) cuts corners or tries to use a shortcut based on members that compare as equal. I *know* that "If two members compare as equal, their order in the sorted array is undefined." *However*, once uasort() has found certain members to be equal, it seems to jump to conclusions based on that and doesn't go on to compare other members to each other that need to be. Say for example you have an array with 3 members, call them A, B, and C, where the callback for uasort() would return 0 for A compared to B 0 for B compared to C -1 for A compared to C It seems that if uasort() compares A to B, and B to C and sees that they are "equal", it never compares A to C, which are not equal. I consider it a bug, and a major flaw, but I don't know for sure that people familiar with the code don't intend for it to work that way. Since uasort() / usort() are billed as the solution for sorting by non-trivial criteria, I really think that it should work more robustly and perform more thorough processing in those situations. If there is some reason it can't be made to work that way, there should be a very noticeable warning in the documentation about how limited its functionality is. I encountered this issue in the course of real world development, trying to tailor the order of output of form elements in Drupal based on its weighting system. The uasort() callback in my reproduce code is the Drupal core code modified to sort members alphabetically if the assigned weight values are equal. Printing the values of the arguments in the callback reveals that "A" and "C" (field_favorite_movies and field_favorite_music) are never compared. Reproduce code: --------------- Source: http://www.jessemccarthy.net/public/uasort_bug/reproduce_source.php In action (with PHP 4.4.4., but the same behavior occurs on another server with 5.2, where I originally encountered it): http://www.jessemccarthy.net/public/uasort_bug/reproduce.php Expected result: ---------------- I expect 'field_favorite_movies' to occur prior to 'field_favorite_music' in the sorted array. I expect 'monkey_wrench' to appear anywhere. Actual result: -------------- 'field_favorite_music' occurs prior to 'field_favorite_movies'. If 'monkey_wrench' is excluded from the original array, the order is correct after sorting. ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=40616&edit=1
