In file stdlib/qsort.c, why is swapping elements code so complex?

[Amit]

On Thu, 29 Jan 2026 at 11:10, DJ Delorie <dj@redhat.com> wrote:
>
> Amit <amitchoudhary0523@gmail.com> writes:
> > So, similarly, if qsort() fails to allocate memory for one element
> > then it can fall back to another """"very simple"""" alternative of
> > swapping elements which involves ""xor"" operator.
>
>
> XOR is a waste in your example anyway.  Once you've read the bytes from
> x[] and y[] just store them back to y[] and x[].  No XOR is needed.
>


I agree that XOR is not needed. But even then there can be """"very
simple"""" alternative code by using an "unsigned char temp" to swap
the bytes.


> > By the way, ""errno"" can be used to indicate failure from the qsort() function.
>
> No, it can't, because POSIX says no errors are defined.  That means we
> cannot modify errno as it may contain a code from a previous failure.
>


Well, POSIX is not quite on the spot here.

Actually, in my opinion (and also, it is the way I code), all POSIX
functions should return an int value as to whether the function call
was successful or not. And if the function needs to return something
else, like number of bytes read, then it can take an integer/long
pointer as an argument and put in the value there.


> Also, since POSIX says qsort can't fail... it can't fail.
>
> > If something was done in the past, it doesn't mean that it can't be
> > improved.
>
> The complex logic you're complaining about *is* an improvement.  Lots of
> effort has gone in to making qsort faster and more robust.


There is always a tradeoff between speed and code complexity. I prefer
code complexity when the performance gains are significant (more than
50% performance gain). Here, in qsort(), the complex code will not be
much more efficient than swapping bytes using a temporary variable.

The main drawback of complex code is that a new developer may not
understand the code fully and so he/she may make some mistakes in
updating the code / fixing the bugs in the code.

""""What I don't understand is why they didn't implement quicksort,
was quicksort too complex for them?"""" If you say that they would
have thought of "something" and that's why they didn't implement
quicksort then I would like to know what that "something" was.
Actually, I know that nobody knows what that "something" was, and I
know that actually this argument is used for defending earlier work
irrespective of whether the earlier work was good or bad.

It doesn't make sense to me that they implemented mergesort which
requires a lot of memory. If the memory allocation for mergesort
succeeds, then the chances are very high that the memory allocation
for one more element will also succeed.

If memory allocation fails for mergesort, then they fall back to
heapsort. """"So, why not implement quicksort in the first place?""""

Someone can defend mergesort by saying that mergesort is stable sort.
Well, POSIX doesn't say that qsort() should do stable sort. Also, no
one cares about stable sort. Some people may but I don't prefer
satisfying a minority of people at the expense of the majority. The
minority can implement their own mergesort if they want a stable sort.


> Sometimes
> that make the code more complex, but most users don't need to read the
> code to use it ;-)
>


It is not about users reading code. It is about a new developer who
takes charge of the complex code.

Amit