On 1/14/05, David Mosberger <[email protected]> wrote:
> I'm seeing the following warning from sparse:
>
> include/linux/jiffies.h:262:9: warning: cast truncates bits from constant value (3ffffffffffffffe becomes fffffffe)
>
> it took me a while to realize that this is due to
> the jiffies_to_msecs(MAX_JIFFY_OFFSET) call in
> msecs_to_jiffies() and due to the fact that
> jiffies_to_msecs() returns only an "unsigned int".
>
> Is there are a good reason to constrain the return value to 4 billion
> msecs? If so, what's the proper way to shut up sparse?
Is there any logical reason to need longer than 46 days of
milliseconds? I mean, sure, we could support years in milliseconds,
but why :) ? If you need longer, specify in seconds. Or add an
interface which does days :) I think it's perfectly reasonable to
constrain time units representative storage in the following manner:
seconds: unsigned int
milliseconds: unsigned int
microseconds: unsigned long
nanoseconds: u64
These are the assumptions I have made in my timeofday-based soft-timer
rework, for what it's worth.
I will look into all the math, though, as all the conversions need to
be accurate for my rework (to support existing interfaces).
Thanks,
Nish
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
