[PATCH] Replace int -> uint to avoid signed integer overflow

Kang-Che Sung explorer09 at gmail.com
Tue Feb 7 07:17:02 UTC 2017


(Forgot to CC the mailing list on the last sent mail. Resent to CC the
mailing list)

On Tue, Feb 7, 2017 at 6:59 AM, Rob Landley <rob at landley.net> wrote:
> My attitude towards false positives may have been influenced by people
> running static checkers against toybox and submitting long spreadsheets
> of results, which I've spent hours going through and writing up my
> analysis of each hit, although I spent a lot more effort on it the first
> few times it happened:
>
> http://lists.landley.net/pipermail/toybox-landley.net/2014-February/003280.html
>
> My reluctance to "fix" non-bugs may have been informed by that sort of
> thing. SOMEBODY has to be able to reproduce the issue, or at least
> feasibly explain what they think might occur.

Sorry for off-topic reply, but in your mail pointed by the URL above, I should
say that some of the cppcheck complaints make sense. Well, that's what
cppcheck was supposed to do. It can't assume your libc version, and for
portability's sake it will better warn you than being silent.

Take the "scanf without field width limits can crash with huge data" for
example, I hope you have read this cppcheck's developer's reply:
    https://stackoverflow.com/questions/9292861/

In short, you are right to argue that it's libc's fault and not yours,
however, do note that POSIX [1] didn't yet specify integer overflow
behavior for scanf. If a libc implementation uses strtol() internally for
scanf integer parsing then you're safe, but I'll suggest switching to strtol
if possible to ensure a defined behavior instead.

(And take advantage of endptr:
sscanf(str, "%u%n", &u, &count);
/* equivalent */
u = strtol(str,&endptr,10), count = (int)(endptr-str);
)

If you wish to ignore the complaint, that's your choice.
I'm just to show an idea.

[1] (http://pubs.opengroup.org/onlinepubs/9699919799/functions/scanf.html)


More information about the busybox mailing list