newlib: PRIx8 inttype incorrectly resolves to `hh` with newlib-nano

[stephanosio]

Describe the bug
The hh format modifier (e.g. %hhu), which is used for the [u]int8_t types, is not supported by the Zephyr SDK newlib-nano build because the nano variant builds without the _WANT_IO_C99_FORMATS option:

		case 'h':
#ifdef _WANT_IO_C99_FORMATS
			if (*fmt == 'h') {
				fmt++;
				flags |= CHARINT;
			} else
#endif

Noting that the newlib-nano build does not support the hh modifier, the PRIx8 inttypes should not resolve to hh*; instead, they should resolve to one of the closest types (e.g. h*).

To Reproduce

Run the following code with CONFIG_NEWLIB_LIBC=y and CONFIG_NEWLIB_LIBC_NANO=y:

#include <stdio.h>
#include <stdint.h>
#include <inttypes.h>

void main(void)
{
        volatile uint8_t a = 92;
        volatile uint8_t b = 254;
        volatile uint16_t c = 4883;

        printf("%hhu.%hhu.%hu\n", a, b, c);
        printf("%%" PRIu8 "\n");
}

Because the hh modifier is not supported with the newlib-nano, the output is as follows:

hu.hu.92
%hhu

Note that PRIu8 resolves to hhu, which is not supported; thereby, rendering PRIx8 inttypes unusable with the newlib-nano.

Expected behavior

When CONFIG_NEWLIB_LIBC_NANO=y, PRIx8 inttypes resolve to %h*, which is the closest to %hh*.

Impact

PRIx8 inttypes are unusable with the newlib-nano.

Environment (please complete the following information):

• OS: Ubuntu 20.04
• Toolchain: Zephyr SDK 0.14.1
• Commit SHA: d5e7732

Additional context

• This problem was originally reported and discussed in Fix version string formatting #45329 (comment)
• The exact same problem is observed with the GNU Arm Embedded toolchain (because the Zephyr SDK has tried to replicate the GNU Arm Embedded build configurations until now).

[stephanosio]

FYI @de-nordic

[stephanosio]

Further investigation revealed two major issues:

1. As expected, there was a header inclusion issue in which the full newlib.h was being included instead of the nano newlib.h even when CONFIG_NEWLIB_LIBC_NANO=y.

   • nano.specs is malformed (see Incorrect newlib.h is used when nano.specs is used sdk-ng#468).

2. Even if the nano newlib.h is included, inttypes.h still resolves PRIx8 to hh*.

   • This is because inttypes.h decides the modifier using the __INT* macros, that is defined in the sys/_intsup.h which infers the types based on the native toolchain types.
   • Note that the SCN*8 definitions are still controlled by the _WANT_IO_C99_FORMATS from newlib.h, so they do get omitted when using the newlib-nano.
   • If any, the same should apply to the PRIx8 inttypes so that they are in sync with the actual built library; but, this would make the PRIx8 definitions unavailable (prints nothing when used) when building with CONFIG_NEWLIB_LIBC_NANO=y, which is unacceptable if we are to start encouraging the use of the PRIx macros to work around Avoid redefining 32-bit integer types like __UINT32_TYPE__ #45248.
   • Reworking the newlib headers to implement the proposed fix in this issue would be high risk and maintenance due to the large amount of changes required to implement it and also that this fix/workaround will not be accepted in the upstream newlib (because it is not fully standard-compliant solution).
   • Since we will need all PRIx macros to be available under all circumstances in order to work around the toolchain type variance issues (Avoid redefining 32-bit integer types like __UINT32_TYPE__ #45248), the only viable option for us is to enable _WANT_IO_C99_FORMATS in the newlib-nano.
   • Note that enabling _WANT_IO_C99_FORMATS is important for being C99 standard compliant -- we should not be optimising the newlib footprint at the cost of breaking C99 compatibility.
   • Also note that increasing the newlib-nano footprint slightly more is not a big concern anymore because we are in the process of introducing the picolibc, which is fully featured yet very lightweight and highly configurable.

In summary, this issue will be fixed by enabling _WANT_IO_C99_FORMATS build option for the newlib-nano so that all C99 format specifiers are supported when using it.