Fw: [PATCH 0/3] libm: Clean up gamma functions

[Keith Packard]

Brian Inglis <Brian.Inglis@SystematicSw.ab.ca> writes:

> I don't get so don't do maths above my comfort level: but it is possible that
> ORs in the specs could mean that some important implementations (e.g BSD and
> glibc) may differ in errors reported depending on which, possibly different,
> exceptional input values are passed. You could check the BSD and glibc specs and
> tests for these functions to see what the expected outputs are for what inputs,
> what exceptional values generate which errno values, and whether all
> possibilities are allowed by all the specs. POSIX always defers to C where the
> latter defines library implementations, but as long as they do not contradict
> normative content, POSIX may add additional conditions or
> requirements.

Yeah, my testing could be more permissive to allow any valid
implementation to pass. Right now, I'm interested in making newlib
compliant with the relevant specs and, where that doesn't conflict,
compatible with glibc. And that means having hard requirements that
match glibc -- I haven't found any places where glibc gets the wrong
answer at least...

There's one place where that's a bit hard -- the gamma function has
changed meaning over time and the current newlib gamma implementation
is closer to the BSD one than glibc, but implements neither exactly.

-- 
-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/newlib/attachments/20200828/43617066/attachment.sig>