[ldexp/frexp] chris...@astron.com said: > You should comment on the PR that started all this in the first place > (different results).
I haven't found a PR to the topic in gnats. Only a commit message about frexp(-0) not being handled correctly. Generally I've kept the libc versions up-to-date if any issues with the libm versions came up, so there are hopefully no significant differences in bevavior. I doubt that any real-life software which uses these functions doesn't link against libm, so the libc code exists only for formal binary compatibility. (I've recently built a system with BUILDCOLD set which removes the compat stuff from libc and everything worked well. Almost everything... A C# program from pkgsrc stopped working - the "mono" runtime dlopen(3)s some libc functions directly and misses the RENAMEs apparently.) Btw, even with the reachovers the libc and libm versions were not identical - libc used the C version of scalbn() while libm uses the i387 asm one (which I've just RENAMEd for namespace sanity). best regards Matthias ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------
