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

[Alain M.]

Hi Martin,

First, let me apologize, I sent the link and failed to see that the 
modifier was there ;-)

 > a char or short int (1 byte values)
A char is not a short int !!! in AVR maybe, but surely not in ARM 
because when int is 32, short int usualy is 16...

K&R says that int is a variable size, defined to be the physical 
machine's accumulator size, it could be 8, 12 (PDP8), even 48 or 64. 
Over the years on 8 bit machines, int is usualy 16 bits so it makes 
sense that short int is 8 bits... You may have seen a lot on the 
internet about Linux programs being "64 bits safe" because everything is 
changing once more.

Cutting short: I haven't seen you code, but if it fixes a documented 
behaviour, it is good.

Notice that s1 was destroyed because if the h modifier was ignored, a 4 
bytes value was written in ibcc overwriting the first two bytes of s1. I 
imagined that with 4 bytes alignment (which IIRC is the default) should 
not happen. Can anyone comment on this, please??

Alain


ml escreveu:
> Hi Alain,
> 
> in the second link you send me i found the modifier
> 
> h : short int (for d, i and n), or unsigned short int (for o, u and x)
> l : long int (for d, i and n), or unsigned long int (for o, u and x), or
> double (for e, f and g)
> L : long double (for e, f and g)
> 
> even gccarm shows a warning : modifier h requires unsigned short int
> so i think it is defined in gcc
> 
> i´m not a c-freak but i use the "%hx"  since many years with different
> compilers and it gives me back
> a char or short int (1 byte values) . Why do you mean it doesn´t solve my
> problem ?
> i can see that it works. after the modification in my example the string
> isn´t destroyed and the variable ibcc contains the right value.
> 
> may be it´s better to use only integers like in all pieces of code i see in
> nut.
> 
>  
> 
> Martin
> 
> 
> 
> Alain M. wrote:
>> 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
>>>
>>>
>>>
>> _______________________________________________
>> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
>>
>>
>