decimal floating point

[Steve Summit]

Greetings.  I haven't posted to this list before, but I think I
know some of you, and some of you may recognize my name as the
maintainer of the old comp.lang.c FAQ list.

I've become interested in decimal floating point.  Now that
IEE754-2008 supports it, and C23 supports it, and gcc supports
it, there's an obvious wish for glibc to support it.

I'm interested enough in decimal floating point that I'm prepared
to work on it, and in fact I'm interested enough in working on it
that -- if for no other reason than to get a feel for what the
scope of the effort actually is -- I've already completed some
prototype glibc mods to support it, which are working rather
nicely.  (Details on those efforts later.)

But an obvious up-front question is: what about libdfp?  I've
already been in preliminary conversation with Joseph Myers,
who pointed me at this prior message of his on the topic,
from September 2019:

    "Considerations for libdfp integration"
    https://sourceware.org/pipermail/libc-alpha/2019-September/106579.html

(I don't believe there's been any followup discussion.)

There's a pretty fundamental to-be-or-not-to-be question here.
Is the Right Thing to do here to:
* embrace libdfp by somehow adopting and integrating it wholesale
  into glibc, or
* embrace libdfp by making it possible to work seamlessly
  alongside glibc, and calling it the official solution, or
* partially embrace libdfp by integrating parts of it into
  glibc, and rewriting other parts from scratch, or
* leave libdfp as its own separate project, and reimplement
  large swaths of dfp support natively in glibc from scratch?
* (Or something else?)

As Joseph wrote in that email from 2019, "the natural way to do
various things as part of glibc differs from the natural way to
do them as a separate project".

As a relative outsider, I wouldn't presume to barge in here and
assert what I think the right approach is.  It's a darn hard
question, to the point that one almost wishes that libdfp had
never been written as a separate project in the first place,
leaving the decision to implement within glibc unambiguous.

I do think it's pretty clear that there are some features that
almost certainly belong natively in glibc, including printf and
scanf support for %Hf, %Df, and %DDf, and stdlib.h functions
like strtod{32,64,128}.  (These also end up being much more
straightforward to implement than, say, transcendental functions
such as sind64().)

At any rate, my question for today is simply: How much appetite
would there be for full and fully-integrated dfp support within
glibc?  If it's felt that libdfp in its current form already
provides adequate support for anyone who really wants to use
_Decimal32 and friends, then pursuing a "fully integrated"
solution might be seen as undesirable and a waste of time.
Me, my wish is for any old user of a Linux box who's got a
modern, stock gcc and glibc installed to be able to bang out
something like

	_Decimal32 d1 = 123.456df;
	_Decimal64 d2 = 1234.5678dd;
	printf("d1 = %Hf, d2 = %Df\n", d1, d2);

and have it Just Work.  (I am, I freely admit, somewhat of a
dreamer when it comes to wishes like this.)

If there's any interest in such a "fully integrated" solution,
I'm eager to participate in the discussion, and present my work
and the assumptions that went into it.  (Short answer: my current
glibc is well beyond able to make the above fragment work, but
far from complete in its support for every last bit of decimal
floating-point math specified by C23.)  If there's no interest,
I understand -- although if I end up finishing this work anyway, I
might come back later and try to convince y'all to reconsider it. :-)

					Steve Summit
					scs@eskimo.com