🚀 go-pugleaf

In article <4iukhc$5nr@rdsunx.crd.ge.com>, volpe@bart.crd.ge.com (Christopher R. Volpe) writes:
>In article <4it51b$ng8@usenet.pa.dec.com>, diamond@tbj.dec.com (Norman Diamond) writes:
>>>>Just one sentence earlier, you gave the exact reason why
>>>>it doesn't matter if you do "a > b" instead of "a - b".

>>>Of course it matters.  With this function, if compar(x,y) > 0, then
>>>compar(y,x) == 0.  This is not antisymmetric.

>>Argh!  I was remembering what the hardware usually does for comparison
>>instructions, and forgot that C operators lose part of that information.
>>I must be getting Cnile.

>>>(a > b)? 1: (a < b)? -1: 0

>>Yup.  Incidentally, do you think the average implementation's
>>interprocedural optimization phase will change this user function into
>>one machine instruction in the library's qsort() function :-?

>I'd be quite impressed if it did.
>Alternatively, how about this:
>    return ((signed int) ((unsigned int)a - (unsigned int)b));

If this alternative is a reply to my snarky question about quality of
implementation (which was a bit off-topic) then the answer is that it
will probably work even under "reasonable" implementations.  However,
if you're asking what the standard says about your alternative, the
effect is not strictly conforming and again might cause undefined
behavior if the standard requires the comparison function to be reasonable.
The problem is that the conversion from unsigned int to signed int will
be implementation-defined about half the time.
--
 <<  If this were the company's opinion, I would not be allowed to post it.  >>
"I paid money for this car, I pay taxes for vehicle registration and a driver's
license, so I can drive in any lane I want, and no innocent victim gets to call
the cops just 'cause the lane's not goin' the same direction as me" - J Spammer