look for qsort() -- all you have to do is write your own custom comparison function that returns an integer similar to strcmp(). The code below assums you are sorting an int array in descending order.

Or an array of strings, in descending order (I think)

AD: There's no need to cast away constness (it may do no harm, but I avoid things that can be bad habits). And your integer comparison function can be a victim of integer overflow.

>return *i2 - *i1;
Eew. Can we say integer overflow?

>return (x < 0) ? 1 : (x > 0) ? -1 : 0;
Eeeeew! Nested conditional statements are fugly and hard to follow. How about this:

now how can subtracting two integers possibly cause integer overflow?

Narue: I agree your solution is simpler. But don't thumb you nose at nested conditional statements just because you may not understand them. Eeeeew :lol:

Dave: I'm sertain you already know that the two parameters must be cast to the correct type. So I don't know what you meant in your post. I could have posted this, but others, such as Narue, may not have understood it

What's INT_MAX - INT_MIN?

Right, you are incorrectly casting away the constness. Casting with (const int*) would be better.

>now how can subtracting two integers possibly cause integer overflow?
Under is over and over is under. The point is that you could subtract beyond the limits of a signed integer, and Bad Things(TM) happen when you do stuff like that.

>But don't thumb you nose at nested conditional statements just
>because you may not understand them.
If everyone thumbed their noses at nested conditional statements, I wouldn't need to understand them. And the world would be a better place.

>I'm sertain you already know that the two parameters must be cast to the correct type.
And const is there for a reason. But for assignment there's no need to use casts:
When you go directly into a function call, a cast is a good idea, but remember that strcmp expects pointers to const char, not pointers to char. You don't cast to the actual type, you cast to the expected type and hope with all your might that the two types are compatible.

-1 with my compiler -- but you'r right about int overvlow in that one and only case. I don't ever recall any number of real world applications where that will happen, but then I havn't read all real-world programs either

Ok now I see your objection. Easy fix to the purests, but does not really do anything in this situation. But I suppose one should be consistent and use const correctly as you pointed out.

that's one of the purposes of function prototypes, to give the compiler enough information to make correct data type conversions. So you always do this? (I don't)

I never explicitly typecast the parameters to const char*. So why bother in that comparison function I posted ?

And the same thing applies to all functions that take a const something-or-another.

No, but that's what it does with the undefined behavior. (And can you guess how that might screw up a sort?)

Okay, how about subtracting from INT_MAX any negative number? For me that gives a couple billion cases. Then take INT_MAX-1 and a couple billion minus one more. Then take INT_MAX-2 ...

And you could also start on the other side: Subtract from INT_MIN and positive number. Subtract from INT_MIN+1 every number greater than 2.

I'd say there are quite a few combinations of two integers that result in undefined behavior.

[edit]By the way, this is a comparison function I'd run across.