Picolibc printf options in SDK 'integer only' variant?

[keith-packard]

zephyrproject-rtos/zephyr#62444 asks whether the lack of 64-bit integer output support in the 'integer only' printf variant is a bug or a feature. I'd like to hear what others think about this; picolibc offers "long long" printf/scanf support as an optional build feature, but the SDK leaves it disabled by default.

Should we enable this for platforms where 'long long' is 64 bits?

The cost to picolibc is quite modest (about 30-ish bytes of additional code). However, on platforms without a 64-bit divider, enabling this feature pulls in the64-bit software division function, which is pretty large (around 850 bytes on cortex m3). And, of course, this will slow down all integer output as picolibc doesn't provide separate 32- and 64- bit conversion paths (which would only make things still larger).

I'm working on an alternate decimal-to-string conversion path which avoids the division operation and reduces the cost of adding 64-bit support to around 100-150 bytes. It can also provide divide-free conversion for 32-bit values for targets like cortex m0 which don't have a 32-bit divider. picolibc/picolibc#583 Of course, if you enable that and go on to use the division function in other code you've just wasted 100 bytes of text space.