nrf9160 - sscanf() - Length field (%hhi, %hhu)

[ReneDelgado]

Hi,

Currently, we work on a project that uses:

• nRF9160
• Zyphre OS
•  Segger Embedded Studio for  Arm (Nordic Edition) V5.10d
• SDK v1.4
• CONFIG_NEWLIB_LIBC=y
• CONFIG_NEWLIB_LIBC_FLOAT_PRINTF=y
• CONFIG_NEWLIB_LIBC_FLOAT_SCANF=y

We need to use  "sscanf()" function whit length field specifier, here are some examples that we tried and it does not work and it is causing memory corruption in the consecutive variables.

sscanf(jsonString + token->start, "%hhu", i);

sscanf(jsonString + token->start, "%hhi", i);

It would be great if we could use all the standard ISO C format string with characters and conversion specifications.

https://en.wikipedia.org/wiki/Printf_format_string

Would you help us to use correctly this functionality with the nrf9160 environment mentioned?

Thank you,

René D.

[Håkon Alseth]

Hi,

 

sscanf() is provided by newlib, which again comes with your local compiler (arm-none-eabi).

Could you check if the code snippet shown here runs as expected on your end?

https://www.tutorialspoint.com/c_standard_library/c_function_sscanf.htm 

 

I also added this small snippet to the above code, and that ran that:

		char var[100];
		char i;
		strcpy(var, "Something Something: 123");
		sscanf(var, "Something Something: %hhu", &i);
		printk("i: %u\n", i);
		
		int day, year;
		char weekday[20], month[20], dtm[100];
		strcpy( dtm, "Saturday March 25 1989" );
		sscanf( dtm, "%s %s %d  %d", weekday, month, &day, &year );
		printk("%s %d, %d = %s\n", month, day, year, weekday );
		
		k_msleep(1000);

Which prints:

i: 123
March 25, 1989 = Saturday

 

I added the above code in hello_world, with these additional configs:

CONFIG_NEWLIB_LIBC=y
CONFIG_NEWLIB_LIBC_FLOAT_PRINTF=y
CONFIG_NEWLIB_LIBC_FLOAT_SCANF=y
CONFIG_MAIN_STACK_SIZE=4096

 

Kind regards,

Håkon

[ReneDelgado]

Hello,  thanks for your response,

Here is an example that describes better the problem, apparently sscanf () is interpreting the specifier "%hhu" as "%hu". The above causes the next byte to be written incorrectly.

const int8_t str_dummy [8] = "7\r\n";
union dummy_union_t 
{
    uint8_t my_var;
	uint8_t my_array[4];
};
    

union dummy_union_t my_union = 
{
    .my_array[0] = 1,
	.my_array[1] = 2,
	.my_array[2] = 3,
	.my_array[3] = 4,
}; 

printk("******************************** Original array state\n");    
printk("my_array[0]: %hhu\n", my_union.my_array[0]);
printk("my_array[1]: %hhu\n", my_union.my_array[1]);
printk("my_array[2]: %hhu\n", my_union.my_array[2]);
printk("my_array[3]: %hhu\n", my_union.my_array[3]);

printk("******************************** Updating my_var\n");
sscanf(str_dummy, "%hhu", &my_union.my_var);
printk("my_var: %hhu\n", my_union.my_var);
	
printk("******************************** Array after the data update, my_array[1] was corrupted\n");
printk("my_array[0]: %hhu\n", my_union.my_array[0]);
printk("my_array[1]: %hhu\n", my_union.my_array[1]);
printk("my_array[2]: %hhu\n", my_union.my_array[2]);
printk("my_array[3]: %hhu\n", my_union.my_array[3]);

What should we do to use that the "%hhu" specifier correctly?

Thanks a lot,

René D.

[Håkon Alseth]

Hi René,

 

ReneDelgado said:

What should we do to use that the "%hhu" specifier correctly?

As mentioned, the newlib standard functions are provided with the compiler itself, so there might be a bug there or in the handling.

Which version of arm-none-eabi-gcc are you using?

What is the output in your case?

 

Did you try the code that I posted, and how did it behave?

 

Kind regards,

Håkon