Re: [PATCH 04/10] sscanf: fix overflow

2015-05-06 Thread Rasmus Villemoes
On Tue, May 05 2015, Alexey Dobriyan wrote: > On Tue, May 5, 2015 at 12:51 PM, Rasmus Villemoes > wrote: >> On Sat, May 02 2015, Alexey Dobriyan wrote: >> >>> Fun fact: >>> >>> uint8_t val; >>> sscanf("256", "%hhu", &val); >>> >>> will return 1 (as it should), and make val=0 (as it

Re: [PATCH 04/10] sscanf: fix overflow

2015-05-05 Thread Alexey Dobriyan
On Tue, May 5, 2015 at 12:51 PM, Rasmus Villemoes wrote: > On Sat, May 02 2015, Alexey Dobriyan 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 "s

Re: [PATCH 04/10] sscanf: fix overflow

2015-05-05 Thread Rasmus Villemoes
On Sat, May 02 2015, Alexey Dobriyan 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 -

[PATCH 04/10] sscanf: fix overflow

2015-05-01 Thread Alexey Dobriyan
Fun fact: uint8_t val; sscanf("256", "%hhu", &val); will return 1 (as it should), and make val=0 (as it should not). Apart from correctness, patch allows to remove checks and switch to proper types in several (most?) cases: grep -e 'scanf.*%[0-9]\+[dioux]' -n -r . Such