[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [patches] libdfp
- To: "Joseph S. Myers" <joseph@xxxxxxxxxxxxxxxx>
- Subject: Re: [patches] libdfp
- From: Ryan Arnold <rsa@xxxxxxxxxx>
- Date: Mon, 29 Jun 2009 17:13:17 -0500
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