On Fri, 21 Jul 2023 at 10:16, Philippe Mathieu-Daudé <phi...@linaro.org> wrote: > > Hi Peter, > > On 20/7/23 17:58, Peter Maydell wrote: > > 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. > > PL031State::tick_offset is uint32_t, and pl031_get_count() also > returns that type. Is that expected?
I think those fall into the category of "the device we are modelling does not support 64-bit timestamps" -- the PL031 RTC_DR register is only 32 bits. thanks -- PMM
