Re: [IDEA+RFC] Possible solution for min()/max() war

[David desJardins]

Linus Torvalds <[e-mail]> 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