newlib-nano is unable to process sscanf() input after the 1st unsigned char value (%hhu or %hhx)

[TechGuyMike]

When running this code, I get only the first unsigned char value read from the input string, but not any subsequent ones:

int main(void)
{
  char* input = "0 1 2 3 4 5";
  static volatile uint8_t data[6];
  volatile int byte_read_count;

  memset(data, 0x55, sizeof(data));

  byte_read_count = sscanf(input, "%u %u %hhu %hhu %hhu %hhu",
         &data[0],
         &data[1],
         &data[2],
         &data[3],
         &data[4],
         &data[5]);
  return;
}

I'm expecting the array 'data' to contain values 0, 1, 2, 3, 4, 5, but instead I get 0, 1, 2, 0, 0, 85.  This happens only with format specifiers "%hhu" and "%hhx".  As an aside, byte_read_count is set to 3 (this at least matches the number of parameters that are correctly set by sscanf), but I was expecting it to be 6 since I'm trying to read 6 values from the input string.

I've tried other variations of the input/format strings, and sscanf always correctly reads the first %hhu parameter in the format string, then fills the next two parameters with zeroes and ignores the rest. This appears to be a bug in newlib-nano.

Also, when using %u or %hu instead of %hhu, everything works correctly.

I was able to narrow this issue down to the newlib-nano standard C library since when I switch to the standard newlib, this issue goes away.

I'm using CubeIDE 1.13.2 (the latest currently available) with all the latest updates for libraries and tools installed.

Hopefully, this issue can be resolved in the future releases.

[Pavel A.]

Please see this thread

https://community.st.com/t5/stm32-mcus-products/proper-way-to-use-scanf-with-uint8-t/m-p/602630

TL;DR  Not a bug. Limitation of chosen newlib-nano configuration.

[Tesla DeLorean]

Trade offs made size vs versatility, the kitchen sink is quite large.

Consider perhaps atoi() ? or something even cheaper..

[TechGuyMike]

Thanks, but that link takes me to the page where the accepted answer is that I should be using the regular newlib, which is what I've already found out on my own (see my original post).

If this is a limitation of the newlib-nano library, it needs to be documented in the IDE user guide. The user guide explains the limitations related to floating-point numbers, but doesn't mention this one as either a limitation of the library or a bug.

If it's not an official limitation of the library, then it's a bug that needs to be fixed - and also documented in the user guide.  I don't know how ST builds newlib-nano, so only ST can definitively answer the question regarding the support of the hh attribute in sscanf() function.

[TechGuyMike]

It might be a trade-off, but then it needs to be documented in the IDE user guide just like they documented other trade-offs. And if it's not a trade-off, then it might be a bug that should be fixed.

[Tesla DeLorean · Accepted solution]

Not sure it's the IDE's, but those who developed the variant. Perhaps the marquee could be bigger, but these aren't limitations ST invented.

"The Newlib nano variant ( libc_nano. a and libm_nano. a ) is the size-optimized version of the Newlib, and supports all features that the full variant supports except the new format specifiers introduced in C99, such as the char , long long type format specifiers (i.e. %hhX and %llX )."

https://docs.zephyrproject.org/latest/develop/languages/c/newlib.html

"b) support only conversion specifiers defined in C89 standard. This brings us good balance between small memory footprint and full feature formatted input/output."

https://github.com/32bitmicro/newlib-nano-1.0/blob/master/newlib/README.nano