On Tue, 28 Aug 2001, Linus Torvalds wrote:
> It was not davem who added the type argument. It was me who _required_
> that min/max be very much explicitly type-aware, as I consider any other
> alternative to be inherently buggy.
Sure. Any attempt to keep the old min/max and make them automagically
do the right thing is doomed since there is no _single_ right thing
we want from them and choice should be deliberate and explicit. No
arguments here.
> generating correct code. And that's to a large degree because they
> force the user to specify what type he _thinks_ the comparison should be
> done in.
<nod>
> The problem with putting the "type" in the name of the function/macro
> is/was that
>
> - there's a _lot_ of types. David actually had a version for this, and
> there were separate versions for everything ranging from "int" to
> "uint", to "s32" to "u32", to "size_t" etc etc.
Ugh. I have a serious feeling that most of them would be redundant, but...
OK, I guess that somebody might want "unsigned max of x and y % 256" (x
being unsigned char and y - unsigned long). Yes, with stuff like that
we'd really need a function for every type, but I would be very surprised
if somebody actually needed that (and I'd rather see it written explicitly,
regardless of the mechanism we use).
> - Some people would _still_ not understand what the advantage of
> explicit typing would be, so we'd have drivers doing their own
> min/max functions, not understanding the issues about signs and C
> type conversion.
Well, that's what grep is for. Bet that we'll see MAX, __max, m4x and
all sorts of similar "workarounds", so grep'n'LART will be needed anyway.
-
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/
This archive was generated by hypermail 2b29 : Fri Aug 31 2001 - 21:00:27 EST