Closed GoogleCodeExporter closed 9 years ago
Does this fix any theoretical or practical bug or is it just for correctness?
Original comment by dorma...@rydia.net
on 26 Feb 2012 at 9:36
I believe c99 made intmax_t safe for printing/conversions no matter what the platform. This, I believe, helps handle netbsd's usage of 64bit time_t on all platforms.
As far as a potential bug, I think it would depend on the implementation of
time_t and be related to settings items to expire way way in the future or
having a system with many many years of uptime on items that never expire.
Original comment by msporleder@gmail.com
on 26 Feb 2012 at 1:42
Wether this patch is taken or not,
these lines:
- APPEND_NUM_FMT_STAT(fmt, i, "age", "%u", current_time -
tails[i]->time);
- "%u", itemstats[i].evicted_time);
should probably be cast
Original comment by msporleder@gmail.com
on 26 Feb 2012 at 2:20
I'm not sure at all what to do with this change...
You're saying that on some platforms time_t is 64bit, so process_started would
be 64bit.
rel_time_t will always be an unsigned int, if we change that to intmax_t it's
going to end up being the largest integer available on that platform and will
eat into the item size. So intmax_t is more useful for casting?
This seems related to a y2038 bug... I'm going to close it though. If you can
show some test code that fails on some specific platform I can use that to fix
it, but the patch potentially changes memory usage and has casting that could
fail on things I don't have access to.
Sorry :/ 2038 bug is something we'll need to fix at some point, but I don't
think it'll be this way.
Original comment by dorma...@rydia.net
on 29 Jul 2012 at 11:36
Original issue reported on code.google.com by
msporleder@gmail.com
on 25 Feb 2012 at 8:27