Re: [PKT_SCHED] cls_basic: Use unsigned int when generating handle

[David Miller <davem@davemloft.net>]

From: "Nordlund Kim (Nokia-NET/Helsinki)" <Kim.Nordlund@nokia.com>
Date: Wed, 27 Sep 2006 14:45:21 +0300 (EEST)

> But for signed types it falls under this:
> 
>     6.5 Expressions
>     5 If an exceptional condition occurs during the evaluation of an
>     expression (that is, if the
>     result is not mathematically defined or not in the range of
>     representable values for its
>     type), the behavior is undefined.
> 
> Already the initial assignment of 0x80000000 to int falls under this:
> 
>     6.3.1.3 Signed and unsigned integers
>     1 When a value with integer type is converted to another integer type
>     other than _Bool, if
>     the value can be represented by the new type, it is unchanged.
>     2 Otherwise, if the new type is unsigned, the value is converted by
>     repeatedly adding or
>     subtracting one more than the maximum value that can be represented
>     in the new type
>     until the value is in the range of the new type.49)
>     3 Otherwise, the new type is signed and the value cannot be
>     represented in it; either the
>     result is implementation-defined or an implementation-defined signal
>     is raised.
> 
> Of course it can be argued whether the gcc optimization is sane. But it
> seems not to be wrong, and there is no justification for writing the code
> to be unspecified.

Correct, and actually this undefined behavior turns out to be
critical for several types of loop optimizations which I feel
totally justifies the interpretation gcc is using now.

I'll apply Thomas's original patch, thanks.