question about sign of DFP interest

[Steve Summit]

Joseph Myers wrote:
> On Thu, 12 Feb 2026, Steve Summit wrote:
>> So is there any sense that DFP support of some flavor definitely
>> does not belong in glibc?
>
> Who would use the code?

Well, when you implement a standard, you're not really
supposed to ask that question, but I'm happy to answer.
(And, yes, __STDC_IEC_60559_DFP is an optional feature.)

So, first of all, *I* would.  That's why I'm here: When I heard
that C23 had added decimal floating point, and that gcc had
already implemented it, I wanted to try it, but it didn't work,
in that I couldn't even printf a dfp number.  So, thanks to
things being open source, I was able to download the glibc
sources and start adding things myself.

But then, any C programmer might want to use DFP, now that it's
part of the Standard.  For one thing, many programmers, when
they're first playing with floating point, and encountering
surprises such as that 0.1 + 0.2 != 0.3, and asking about these
surprises online, are told that they're due to "deficiencies in
IEEE754 floating point" and that they "might want to try using
decimal floating point instead."  Python, Perl, Java, and
JavaScript programmers are able to do so, with various decimal
packages for those languages being available.  Me, I love C,
so I'd like C to support decimal also.

(Disclaimer: Yes, I know, IEEE754 binary floating point is not
really "deficient", and as long as you know what you're doing,
all those surprises like 0.1 + 0.2 != 0.3 are no problem at all.
Don't get me wrong, I *love* IEEE754 binary floating point, its
speed and precision, and it kills me that so many people conclude
that it's "broken" just because it's not decimal.  But I'm not
convinced that *everyone* should necessarily have to learn how
to use binary floating-point correctly if they're not ready to.)

You asked about "software packages in GNU/Linux distributions".
I haven't talked to its maintainers, but I've heard that earlier
versions of GNU Cash kept balances using native floating point,
until the impossibility of getting it to round correctly forced
them into using hand-rolled decimal fixed point instead.  It's
conceivable that decimal floating point would be an attractive
choice for them.  In a similar vein, I know that Microsoft Excel
implements various hideous kludges in order to use hardware
floating point but make it act like decimal.  I don't know where
Gnumeric stands on this issue, but conceivably DFP arithmetic
might be attractive to it, too.

The bottom line, for me, is that having the feature officially
specified in C23 is a good enough reason to implement it,
especially when gcc's implementation is (imo) useless without
printf support.  (There are some optional C language features --
of course I'm thinking of the Annex K "safe" string functions --
that are so problematic that they're not necessarily worth
implementing, but for me, DFP doesn't fall into this category.)

Anyway, that's why I think this is worth doing.  I'm sure these
justifications won't be compelling to all, but I hope I've at
least suggested that it's not a *completely* frivolous exercise.
For your other questions, all the "Who would maintain?" ones,
this reply is long enough for now, so I'll hold those for later.

					Steve Summit
					scs@eskimo.com