[En-Nut-Discussion] sscanf bug or feature ? %hx

[Alain M.]

Hi,

According to 
<http://www.cplusplus.com/reference/clibrary/cstdio/sprintf.html>
for sprintf the modifier "h" is for <short int> but there is not a 
universal definition that it should be 16 bits (what should be short if 
int is 64 bits?). This should be 16 bits in ARM

BUT in <http://www.cplusplus.com/reference/clibrary/cstdio/sscanf.html> 
ther is no "h" modifier to scanf...

So, before adopting your modification, do you have references of this 
modifier?

AND, anyway, it dos not justify the problem that you are getting, so 
*something* is wrong, but we should be sure of what is wrong...

Alain

ml escreveu:
> Hi 
> 
> a problem with sscanf. When using %hx i see that it isn´t working and it
> overwrites memory
> 
> example
> 
> void test(void) {
>   unsigned short int ibcc;
>   char          s1[]  = "41";
>   sscanf(s1,"%2hx",&ibcc);
> }
> 
> after sscanf s1 is destroyed showing "4("and ibcc contains 0 
> 
> i see that getf.c doesn´t check the h modifier. function allways returns int
> or long so memory is overwriten
> when using a char or short int.
> 
> 
> 
> i changed nut/crt/getf.c
> to use h modifier 
> and give back a pointer to char 
> for this i have to introduce an new flag CF_SHORT (MSB in flags seems to be
> free for this)
> so now it works correct. 
> 
> i don´t know if anyone is interested in this or how to contribute this minor
> change. 
> 
> Martin
> 
> 
>