This patchset was prompted by a couple of Coverity warnings (CID 1507157, 1517772) which note that in the m48t59 RTC device model we keep an offset in a time_t variable but then truncate it by passing it to qemu_get_timedate(), which currently uses an 'int' argument for its offset parameter.
We can fix the Coverity complaint by making qemu_get_timedate() take a time_t; we should also correspondingly make the qemu_timedate_diff() function return a time_t. However this will only push the issue out to callers of qemu_timedate_diff() if they are putting the result in a 32-bit variable or doing 32-bit arithmetic on it. Luckily there aren't that many callers of qemu_timedate_diff() and most of them already use either time_t or int64_t for the calculations they do on its return value. The first three patches fix devices which weren't doing that; patch four then fixes the rtc.c functions. If I missed any callsites in devices then hopefully Coverity will point them out. This patchset is a migration compat break for the aspeed boards, because the offset field in aspeed_rtc is in its vmstate struct. We could in theory make this a compatible migration change, but I don't believe we care about migration compat for these boards. I've only tested this with 'make check' and 'make check-avocado', which probably do not exercise these RTC devices much. I've tagged this as for-8.2 because the code has been like this forever. We might as well give ourselves plenty of time to see if there's any unforeseen consequences of widening the type. thanks -- PMM Peter Maydell (4): hw/rtc/m48t59: Use 64-bit arithmetic in set_alarm() hw/rtc/twl92230: Use int64_t for sec_offset and alm_sec hw/rtc/aspeed_rtc: Use 64-bit offset for holding time_t difference rtc: Use time_t for passing and returning time offsets include/hw/rtc/aspeed_rtc.h | 2 +- include/sysemu/rtc.h | 4 ++-- hw/rtc/aspeed_rtc.c | 5 ++--- hw/rtc/m48t59.c | 2 +- hw/rtc/twl92230.c | 4 ++-- softmmu/rtc.c | 4 ++-- 6 files changed, 10 insertions(+), 11 deletions(-) -- 2.34.1
