The final version evoked a compile-time error instead of BUG(), and
also was more careful about the kind of zero it compares with! Linus
okayed it in principle and "real life" tests showed that it works
and catches what it's supposed to catch. For me it turned up one
kernel report (in tun.c) and three more in the xfs patches. The
trial covered about a quarter of the kernel.
Some people spotted that the error case can probably be reduced to
large signed versus small unsigned, both of size at least int.
> end of this email. This was the result of someone's `fanciful comment'
> `what if gcc could handle "if(strcmp(typeof(a),typeof(b))!=0)"'.
>
> So here is the important part. The code Peter has introduced a cast
> in the lines "const typeof(x) _x = ~(typeof(x))0;" etc. I think that
> the approach of declaring a variable of the type and initializing to
> zero and then comparing "x - 1" _might_ be better.
I don't know. I intended only to turn the sign bit on. I'm not sure how
1's complement arithmetic works, so I don't know if it works for 1's
complement arithmetic.
> The version of min() at the end calls the following an error, were
> Peter's does not [after removing the sizeof() restriction].
>
> unsigned char Cx = 1; unsigned int Ix = 1; unsigned long Lx = 1;
> Ix = min(Cx,Ix); Lx = min(Cx,Lx);
>
> Here the unsigned char is being promoted to int as discussed before.
> I think that this is `more faithful' as what we are try to achieve is
When someone states what the problem is exactly, and what portion
of it they want to test for, then the test can be modified to suit.
I intended to show that the test can be performed and a two
arg min thereby retained.
> to check the sign that will be used in the min comparison; almost
> like applying a proper warned signed selectively to the min/max
> macros.
>
> Otherwise, I think we have independently came up with the same thing
> and the `error' throwing can of course be changed to whatever.
Probably!
Peter
-
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/