Re: [PATCH for-8.2 0/4] rtc devices: Avoid putting time_t in 32-bit variables

[Markus Armbruster <armbru@redhat.com>]

Peter Maydell <peter.maydell@linaro.org> writes:

> On Fri, 21 Jul 2023 at 10:03, Philippe Mathieu-Daudé <philmd@linaro.org> wrote:
>>
>> +Markus
>>
>> 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.
>>
>> Do we need to change the type of the RTC_CHANGE event?

[...]

> If I understand the 'Built-in Types' section in
> docs/devel/qapi-code-gen.rst correctly, the QAPI 'int'
> type is already 64 bits.

Correct.  Also needlessly confusing.