Messages in this thread | | | Date | Mon, 3 Sep 2001 13:35:52 -0700 | From | David desJardins <> | Subject | Re: [IDEA+RFC] Possible solution for min()/max() war |
| |
Linus Torvalds <torvalds@transmeta.com> writes: > I have one thing to say to people who do not like the new min/max > functions: most of them probably never even _understood_ the multitude > of bugs that are inherent in the classical > > #define min(x,y) ((x) < (y) ? (x) : (y))
I think you're mistaken about what people understand.
The explicit typing of MIN and MAX will avoid some bugs that have to do with the comparison of entities of different types. The explicit typing will also introduce some bugs, when a user uses the wrong type (e.g., when the code is initially written with the correct type, but then someone later changes the type of the variables, and doesn't remember to change the type in the macro call). Overall, I think it will be about a wash.
If this is really a serious problem, then people shouldn't be using the comparison operators like "<" either, as they have exactly the same problem when used to compare objects of different types (particularly since C has such broken rules for deciding what type to use when comparing objects of different types). Instead, we should have LESSTHAN(type,a,b), etc.
I think the best approach to bug avoidance would be two-argument MIN and MAX functions which require that both arguments have the same type, but where that can be any type. Then users who want to compare objects of different types would have to explicitly cast one to the type of the other (or both to a third common type). In the most common case where users are simply comparing objects of the same type, there would be no need or reason to change the code.
It's simple enough for an external checker to confirm that this rule is followed. The same checker could enforce the same rule for "<" and other comparison operators, which would probably help eliminate several bugs (without the unacceptably clunky LESSTHAN macro).
I think no one who is comparing objects of two different types can legitimately complain about being asked to cast one (or both) of them to a common type: the user, rather than the compiler, should indeed choose the type of the comparison. But that's different from redundantly adding the type everywhere to comparisons of objects of the same type, which introduces, rather than eliminating, a source of error.
-- David desJardins - 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/
| |