Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240613010654.GV10433@brightrain.aerifal.cx>
Date: Wed, 12 Jun 2024 21:06:55 -0400
From: Rich Felker <dalias@...c.org>
To: "Ram Nalamothu (QUIC)" <quic_vnalamot@...cinc.com>
Cc: "musl@...ts.openwall.com" <musl@...ts.openwall.com>
Subject: Re: Integer only print functions support in MUSL

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

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.