Re: [patches] libdfp

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

On Mon, 29 Jun 2009, Mark Mitchell wrote:

> Ryan Arnold wrote:
> 
> > We want to get libdfp into existing distros that use an older GLIBC or
> > EGLIBC and don't want to upgrade yet.
> > 
> > Additionally, Some GLIBC based distros are opposed to the addition of
> > add-ons that didn't originate in official GLIBC tree.
> > 
> > We feel that, as an extension to the C library, Libdfp belongs near
> > GLIBC/EGLIBC but as a matter of gaining adoption it needs to exist as a
> > standalone library until ratification of the Draft DFP ISO C Technical
> > Report.
> 
> Joseph, do you have any thoughts on this?

I'm not clear on what ratification has to do with existing as standalone 
or not standalone.  In any case, the ISO catalogue shows that TR 
24732:2009 was published 2009-01-05 and is available for 112 Swiss francs.

IS 24747, TR 18037, TR 19769, TR 24731-1 are also published documents; TR 
24731-2 is still in draft form.  TR 24731-2 is the only one of these C 
extensions for which glibc has even partial support, although all do 
include some library features.  A TR is not an amendment to the C 
standard, whether ratified or not, and nor is a separate IS (IS 24747 - 
mathematical special functions - which can perhaps best be seen as being a 
separate set of C APIs an implementation might implement in the same way 
as POSIX provides such a set of APIs, albeit in this case originating from 
WG14).  TR 19769 (Unicode strings) is the only one of these so far to have 
its library facilities integrated in C1x, although it is proposed for the 
TR 24731-1 interfaces to go in an optional Annex.

Except for TR 19769, whose library interfaces go entirely in a new header 
uchar.h, every one of those TRs (and one IS) adds interfaces to an 
existing header from the C standard or modifies the requirements on such 
interfaces (e.g. adding printf formats), and in that sense is closely 
enough linked to libc that modification of libc headers would be an 
appropriate part of implementing it.  It's also the case that building a 
separate .so file as far as possible is still useful to avoid runtime 
overheads for users who do not need the extra functionality, and that 
#include_next with headers in a separate directory may be used to avoid 
modifications to the glibc headers.

There are some cases where technical requirements clearly dictate using an 
add-on: if the library uses glibc internal source files in its build, or 
if it provides sysdeps files that replace some files while building glibc 
(the latter rather prevents building separately from glibc, of course).  
There are some cases where a library is essentially unconnected with libc 
functionality and clearly should be separate.  (ncurses has or had support 
for building as a glibc add-on, which never made sense to me but does 
illustrate that it is possible for the same code to build both as an 
add-on and independently.)  And there are cases inbetween, such as this, 
where technically you might follow either approach but the library is 
fairly closely connected to ISO C functionality.

The question of what goes in the EGLIBC repository is also one of how 
closely related something is to C library functionality.  Add-ons seem 
appropriate, as do tools such as cross-localedef that use glibc internal 
source files to provide closely related functionality.  But if code does 
not depend on glibc sources, and is not involved in the process of 
building and installing glibc in a native or cross environment, it seems 
less relevant to the EGLIBC repository.

For every one of the six C extensions above, an implementation for use on 
GNU/Linux systems with GLIBC or EGLIBC would be useful to some users - 
maybe only a very small proportion of users in some cases, but they would 
still be useful.  (Any interest in implementations of those other than 
24732 and 24731-2 has been sufficiently limited not so far to lead to 
actual implementations for such systems, however - some of the documents 
would of course take a substantial amount of work to implement.)  If these 
features are implemented in future, we can then consider whether inclusion 
in the EGLIBC repository is appropriate on the same basis as we arrive at 
for libdfp - and I think the question of whether there are technical 
grounds for being an add-on (using glibc source files, needing the sysdeps 
search paths to match glibc, modifying the build of glibc itself) is an 
important part of this.

-- 
Joseph S. Myers
joseph@xxxxxxxxxxxxxxxx