[lkml]   [2015]   [Sep]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch 27/95] scanf: fix type range overflow
On Wed, Sep 9, 2015 at 3:36 PM,  <> wrote:
> From: Alexey Dobriyan <>
> 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.


 \ /
  Last update: 2015-09-10 02:01    [W:0.066 / U:8.320 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site