On 2023-01-16 17:16:59 +0100, Krzysztof Kozlowski wrote:
>> Although very unlikely, the 'clk_num' value may be as big
>> as 2**32 - 1 (uint32_max),
> How it could be that high? Code has num_clks defined from 1
> to 4 and it is used as strict boundary for the loop so how
> it could end up here with higher value?
That's why I called this "very unlikely". However, nobody can
definitely exclude the possibility of extending this limit in
the future.
> s3c24xx_serial_getsource() also returns value & with mask,
> so up to 4 max.
Possibly, clk_num should be uint8_t then - so the buffer size
could be extended up to only 17 bytes ("clk_uart_baud255\0")
with format specifiers changed to "%u", or 18 bytes for "%d"
(clk_uart_baud-128\0).
> This does not look like real issue but some change to satisfy
> static code analyzers, so I don't think it's correct approach.
Although I agree this is probably only a theoretical issue, it's
always easier to spend several bytes than to prove that we don't
need to.
But, anyway, the final decision is up to you.
--
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net
Attachment:
signature.asc
Description: PGP signature
