Re: [patches] libdfp

["Joseph S. Myers" <joseph@xxxxxxxxxxxxxxxx>]

On Mon, 29 Jun 2009, Mark Mitchell wrote:

> Even the question of whether or not to put new APIs in a different .so
> is not obvious; if most applications will want the new APIs, then they
> probably should not be in a separate .so, as that will increase overhead
> rather than reduce it.

I expect the vast majority of applications on a GNU/Linux system are never 
going to have any use for decimal floating-point (and many embedded 
GNU/Linux systems will live just fine without having libdfp at all), so 
having libdfp as a separate .so file is the right thing in this case.  If 
many applications start pulling in libdfp at runtime, it will be because 
someone decided to put functionality using it in a desktop environment 
library or some other such widely used library, even those most of the 
desktop applications that end up pulling in libdfp have no real use for 
that functionality.

The same applies to the special mathematical functions from IS 24747 
(which I think are also the only significant part of C++ TR1 not to be 
going in C++0x - going in a separate IS for C++ as well - because of the 
implementation cost for a limited range of users) - even most libm users 
are unlikely to need them - and the fixed-point interfaces in TR 18037.  
It seems plausible the other three TRs could end up being more widely 
used.

> In this case, it seems like we all think the technically best answer is
> to make DFP an add-on, in the traditional GLIBC sense of the word.  But,
> apparently, Ryan thinks that's not going to be successful, for
> non-technical reasons.

I'm not sure we have a technical conclusion on this either way (given the 
constraint - imposed by needing to work with FSF GLIBC - on not modifying 
core libc files in support of DFP; without that constraint, the case for 
an add-on would be much clearer).

-- 
Joseph S. Myers
joseph@xxxxxxxxxxxxxxxx