Fabian Schriever writes: > Hi Keith, > > We welcome your efforts to clean up - and correct the error return > values of - the gamma/lgamma/tgamma families. Thanks! I'm doing continuous integration testing as a part of embedded toolchain support for RISC-V as part of my SiFive dayjob; fixing bugs like this is part of that process. > We would favor the removal of all non C/POSIX(+XSI)-standard functions > from the interface. Oh, that's probably the best idea of all. Applications should not be using 'gamma' at all given the different definitions over time and space. Any thoughts about the newlib __ieee754 interfaces? Those are essentially the same as the C/POSIX interfaces but do not use errno or other global variables, reporting exceptions only through the fenv API. > If something was changed in 2002, that is working incorrectly and no one > found out until now, that is also not part of any standard, it suggests > that no one is actually using it and should be able to be safely > removed. Does Newlib have a policy to remove elements? I don't think it's 'newlib' which would need any policy; newlib is used downstream in a wide variety of projects, including cygwin and picolibc, which may have separate policies. Cygwin has binary interface definitions, changing those could affect applications there. I'm using newlib as part of picolibc which is used for embedded toolchains where removing things from the ABI to fix bugs would be just fine. > An interesting discussion about the standard lgamma/tgamma functions > would be to discuss accuracy improvements in line with the glibc > improvements from Joseph Myers (see > https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=050f29c18873ec05ba04a4034bed8cb3f6ae4463). I read through that patch and agree that it would be nice to incorporate something similar. We need to be cautious as code cannot be directly brought in from glibc due to licensing differences. -- -keith