Messages in this thread | | | From | Rasmus Villemoes <> | Subject | Re: [PATCH 04/10] sscanf: fix overflow | Date | Wed, 06 May 2015 09:49:35 +0200 |
| |
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
| |