Re: [musl] Integer only print functions support in MUSL

[Rich Felker <dalias@libc.org>]

On Wed, Jun 12, 2024 at 05:29:59PM +0000, Ram Nalamothu (QUIC) wrote:
> Hi,
> 
> On the subject line topic, is there a plan for integer only print
> functions support in MUSL upstream?
> 
> The newlib seems to support the same since 2004 [1] and one
> immediate scenario using this capability is assert function [2] in
> the C library itself which needs to print only the non-float types.
> 
> Applications that use integer only print functions can benefit from
> this capability in terms of reduced code size by avoiding floating
> point support implementation in the linked print functions.
> 
> I tried a quick search on the mailing list but couldn't find any
> previous discussions on this topic.
> Would it make sense to have the similar support in MUSL as well?
> Would the community be open to accept patches supporting integer
> only print functions?

My leaning is no. There is no major precedent for this, no hard *need*
(it's only an optimization hint to make up for other failed
optimizations), and to do it completely and consistently it's a
combinatoric explosion (doubling the number of printf-family
functions). At the very least you'd need (and this would be
application-unfriendly to have just these) i versions of vfprintf and
vsnprintf; everything else can be built on them.

But to get back to the point, on archs that are hard-float and don't
have an oversized soft-only long double, the size of the floating
point code in printf is around 6k. Only the most extreme environments
would warrant exploding complexity like that to save 6k. A better way
to meet their needs would probably be to provide a way to dummy-out
float support at link-time, by putting fmt_fp in its own TU and having
some trick to keep it from getting linked if you use the right
LDFLAGS. But unless there is a really good documented widespread need
for this, I can't see it making sense to do hacks like that upstream
in musl.

Rich