lkml.org 
[lkml]   [2001]   [Aug]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [IDEA+RFC] Possible solution for min()/max() war
Date


hi,

I just can't see why the new min/max macros are any better than the old
one.

given the following two variables: "signed int i" and "unsigned int j"
assume i=-1 and j=2. we all know that -1 < 2, unfortunately, C doesnt
know that, probably when these values are stored in machineword quantities.
(i.e. no problem wich char and short, but with int on 32bit platform).

now, the new macros come in. we could now either write:

min(unsigned int,i,j) ; case 1
or
min(signed int,i,j) ; case 2


when casting to unsigned int, -1 will become 0xffffffff and
"min(unsigned int,-1,2)" will return 2. this is wrong.

case 2 will give the right result.

but what will happen if the unsigned variable is so large that it will
use the most significant bit?

assume i=-1 and j=0xfffffff0;
still, -1 < 0xfffffff0 is true.

min(unsigned int,i,j)
will give 0xfffffff0 because its < 0xffffffff;
wrong result.

min(signed int,i,j)
will give 0xfffffff0 because it will be cast to -16 which is < -1.
wrong result again.

I think this shows that the type-argument in the macros gain nothing.
Instead, whenever we encounter such a problem, the code should be
closely investigated.

I think that this really is some compiler-issue. signed/unsigned comparison
is okay for char and short, but not for int; looks like the compiler
forgets to set or evaluate the carry-flag, perhaps?

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:01    [W:0.031 / U:0.508 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site