On Tue, Apr 10, 2012 at 3:21 AM, Nick Wellnhofer <[email protected]> wrote:
> On 10/04/2012 05:23, Marvin Humphrey wrote:
>>
>> On Sat, Apr 7, 2012 at 4:42 AM,<[email protected]> wrote:
>>>On Tue, Apr 10, 2012 at 3:21 AM, Nick Wellnhofer <[email protected]> wrote:
> On 10/04/2012 05:23, Marvin Humphrey wrote:
>> If compare(pivot, pivot) returns anything other than 0, we've got big
>> problems.
>
> That's what happened with Integer64s.
Heh... so we've detected the error (eventually)... Victory! ;)
>> I don't think it's in our interest to hide such an error -- better
>> to learn about it as quickly as possible by running off the end of the
>> array and segfaulting.
>
>
> Well, the compare function can be supplied by the user, and I'd prefer that
> we never segfault on bogus user input.
I didn't think we'd exposed the SortUtils routines to users yet, but fair
enough.
How about we throw an exception, then?
if (i == right) {
THROW(ERR, "Element failed to test as equal to itself");
}
If equal elements do not test as equal, the sort is unstable. That can lead
to very subtle and difficult to diagnose bugs.
I don't adding the exception block it will interfere with any compiler
optimizations, since it's not within a leaf block -- we already CALL the
comparator.
Marvin Humphrey
