Messages in this thread | | | Date | Fri, 31 Aug 2001 12:10:58 +0200 | From | Helge Hafting <> | Subject | Re: [IDEA+RFC] Possible solution for min()/max() war |
| |
David Weinehall wrote: > > On Thu, Aug 30, 2001 at 09:16:47PM +0000, Graham Murray wrote: > > Daniel Phillips <phillips@bonn-fries.net> writes: > > > > > More than anything, it shows that education is needed, not macro patch-ups. > > > We have exactly the same issues with < and >, should we introduce > > > three-argument macros to replace them? > > > > Would it not have been much more "obvious" if the rules for > > unsigned/signed integer comparisons (irrespective of the widths > > involved) were > > > > 1) If the signed element is negative then it is always less than the > > unsigned element. > > > > 2) If the unsigned element is greater than then maximum positive value > > expressible by the signed one then it is always greater. > > > > 3) Only if both values are positive and within the range of the > > smaller element are the actual values compared. > > Possibly, but changing the C specification is not really an option here...
Even worse: most microprosessors don't do comparisons that way. They compare either two signed or two unsigned items and do that reasonably fast. This is why C also works this way.
A compiler can be made to use the above standard, but it would generate slow code for all signed/unsigned compares because now there is 3 tests instead of one. This is why language designers don't do that.
You can of course do this explicitly in code if you need that sort of comparison, e.g.
signed a; unsigned b; if (a<0) case1() else if (b>MAX_SIGNED) case2() else if (a<b) case1() else case2();
A nice feature of C is that ugly time-consuming stuff tends to look ugly and time-consuming in code too. So it is easier to avoid. :-)
Helge Hafting - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |