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

[ml]

Hi Alain,

because %c gives only back one char but in my example "41" is the ascii
representation of a hex byte :)
%h is documented a long time. %hh is documented in C99 and the compiler
knows it, so i think it will be
better that it works. 
there are man workarounds thinkable but i´ve never used a compiler before
which doesn´t understand
this (OK Keil uses %b for this). i will switch my old protocol code to use
int so it doesn´t matter. 
in the 32 bit world char seems to be a relict 
my intention for this thread was only to avoid problems for other which will
use the h modifier and run
in the same trap. 

Martin




Alain M. wrote:
> 
> I, personaly, never use never undocumented features or even badly 
> documented. Why not use "%c" that is documented for char* ?
> 
> Alain
> 
> ml escreveu:
>> Hi Alain,
>> 
>> short int on arm-gcc isn´t a char thats right. sizeof tells me same
>> length
>> of integer and short int both 2 bytes. So my mistake was a wrong type
>> cast.
>> (short int to char thats not realy good) 
>> But i´ve seen that the "%hhx" modifier often is used for returning a
>> char. 
>> If you use hh gcc warning shows that a char is expected. 
>> So i changed getf  to use hh and then all is ok. 
>> 
>> I think if the comiler expects such thing than scanf should do it, or am
>> i
>> wrong ?
>> 
>> Martin
>> 
>>  
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
> 
> 

-- 
View this message in context: http://www.nabble.com/sscanf--bug-or-feature----hx-tp15309888p15407295.html
Sent from the MicroControllers - Ethernut mailing list archive at Nabble.com.