Re: [patches] libdfp

[Ryan Arnold <rsa@xxxxxxxxxx>]

On Mon, 2009-06-29 at 21:32 +0000, Joseph S. Myers wrote:
> 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.
> 

Thanks, the finer points on the nature of technical reports is lost on
me.  I understand your point now, that even with ratification there's no
guarantee that this will make it into the C language specification.
Drepper has softened on his position and indicated that in the future
this may be subsumed into GLIBC proper.

> 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.

Reliance upon any GLIBC internal symbols is a matter of convenience from
what I can tell, and not necessity.  The add-on version had strongly
coupled usage of the locale and wide character support functionality
built into the GLIBC internals.  The stand-alone version uses the
external interface to those features.  Likewise, the same is the case
with the strtod interfaces.

> 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.

My current stand-alone implementation provides architecture overrides
via a sysdeps directory structure but it only provides Linux as a target
OS.

Ryan