On Fri, 10 Feb 2012, Geert Bosch wrote: > Right. I even understand where he is coming from. Adding new interfaces > is indeed a big deal as they'll pretty much have to stay around forever.
And: even if the interface is a known, public, standard, stable interface, glibc may still not be the right place. Consider the ISO 24747 special mathematical functions. This is an extension to ISO C (there's a similar extension to C++ with the functions that were in TR1). No doubt implementations would be useful to some people, though I haven't heard of any interest in implementing them for the GNU system, and a good implementation (care about error bounds and performance etc.) would be a lot of work. (There is an implementation of the TR1 versions in libstdc++. It doesn't have anything much in the way of error or performance bounds - it's a generic implementation without precomputed tables, that can involve very long loops calling other functions with such long loops in some cases, and I expect various precomputed tables would be involved in getting particularly good error bounds and performance - but I think simply implementing the functions at all involved a lot of work.) But if you implemented the functions in libm in a fast, accurate way, then suddenly all the code is loaded into everything that uses shared libm, and hardly any such programs actually need these functions - cf. the argument for avoiding decimal floating-point support in shared libc or libgcc when hardly any typical GNU/Linux programs are using that. As a well-defined set of functions a separate shared library probably makes more sense. And given that nothing else in glibc depends on them, there's no need for such a library to be part of the glibc project, which may as well keep a narrower focus. (Bits of libc *do* depend on a few bits of functionality from libm, which get built into libc as well; some things such as rounding mode support and separating numbers into mantissa and exponent are relevant for libc functionality such as printf and strtod.) -- Joseph S. Myers jos...@codesourcery.com
