Hello,

We have a patch to enable format specifiers %lld, %llu (i.e. dealing
with "long long" C types) for Newlib libc in the next Zephyr SDK
release: https://github.com/zephyrproject-rtos/sdk-ng/pull/101

Unfortunately, enabling it also requires to disable
CT_LIBC_NEWLIB_NANO_FORMATTED_IO which accounts for noticeable code
saving in Newlib formatting implementation. The net result of disabling
nano formatting and enabling long long support is +13K/+100% code size
increase for a simple printf() call:
https://github.com/zephyrproject-rtos/sdk-ng/pull/101#issuecomment-524606258

I personally vote up this change because:

1. The reason we have the Minimal libc in Zephyr, even as the default,
is to exactly because of things like that: minimal libc is what we
carefully size-control and optimize (and so should continue do that in
the future, and it should stay the default).

2. On the other hand, there should be a way to port existing software
(a lot of software!) to Zephyr without being swamped with patching it.
And Zephyr lacks many things in that regard so far, so porting existing
code becomes a firefighting with array of issues. If we can cross some
of those issues in 3rd-party components now, and concentrate on things
which belong to Zephyr, we should do that.


But in general, I find it pretty surprising that I advocate changes
which increase the codesize of a simple app twice. Maybe, there're
people with good arguments on the other side?

--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog