lkml.org 
[lkml]   [2015]   [May]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH 04/10] sscanf: fix overflow
Date
On Tue, May 05 2015, Alexey Dobriyan <adobriyan@gmail.com> wrote:

> On Tue, May 5, 2015 at 12:51 PM, Rasmus Villemoes
> <linux@rasmusvillemoes.dk> wrote:
>> On Sat, May 02 2015, Alexey Dobriyan <adobriyan@gmail.com> wrote:
>>
>>> Fun fact:
>>>
>>> uint8_t val;
>>> sscanf("256", "%hhu", &val);
>>>
>>> will return 1 (as it should), and make val=0 (as it should not).
>>>
>>
>> What do you base these "should" and "should not" on? Both C99 and POSIX
>> say that the behaviour is undefined - the kernel can obviously define
>> its own semantics for scanf, but what do you think they should be?
>
> POSIX can say whatever it wants,

That was sort of the point, POSIX doesn't say anything, which is why I
asked what you think the semantics should be.

> it's about common sense.
>
> sscanf(), both kernel and libc, in this situation returns 0 when "0"
> character is nowhere to be found in the string! It should either
> return 25

Really? Do you consider it common sense that sscanf("256 123", "%hhu%d", &x,
&y) can end up returning 2, putting 25 in x and 6 in y?

> or do not return anything

I agree that _that_ would be the sane thing to do, but again, I'm
confused why you then said the first example should return 1.

Rasmus


\
 
 \ /
  Last update: 2015-05-06 10:21    [W:0.092 / U:0.888 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site