Messages in this thread | | | Date | Wed, 9 Sep 2015 16:52:29 -0700 | Subject | Re: [patch 27/95] scanf: fix type range overflow | From | Linus Torvalds <> |
| |
On Wed, Sep 9, 2015 at 3:36 PM, <akpm@linux-foundation.org> wrote: > From: Alexey Dobriyan <adobriyan@gmail.com> > Subject: scanf: fix type range overflow
This is another patch that claims to fix a bug, but looks fundamentally broken unless I'm misreading something.
Like it or not, people write code like
unsigned int x;
and then may well initialize it with "-1" or with 0xffffffff depending on how they feel and what helper macros etc they used.
And I see no reason to believe that the same wouldn't be true of sscanf(). In fact, I'm pretty sure it happens exactly for things like initializing bitmasks etc.
But you seem to want to make this an error, because your seem to verify that the underlying numerical value it fits in whatever (signed/unsigned) type that is being converted.
Maybe I misread the code, but that's what it looks like.
And it's wrong. People may use "%d" for "unsigned int" exactly because they want the "-1" to work, but "4294967294" should work too.
> Fun fact: > > uint8_t val; > sscanf("256", "%hhu", &val); > > will return 1 and make val=0 (clearly bogus).
Fun fact: overflows are not at all always clearly bogus.
Come to think of it, I think that the parse_integer() interface may have had the same bug.
Too much "I know better than you" is actually a bug.
Linus
| |