libm exports the following undocumented symbols
        libm: 'drem' not man'd
        libm: 'dremf' not man'd
        libm: 'frexpf' not man'd
        libm: 'ldexpf' not man'd
        libm: 'matherr' not man'd
        libm: 'modff' not man'd

the simplest thing for frexpf, ldexpf & modff is to add them to the
existing frexp, ldexp & modf man pages. But those functions are in libc.

Should the 'f' versions be moved from libm to libc ?
[the existing ones in libc are in the arch-specific part of libc, though a
brief eyeball showed no arch-specific diffs. Should the 'f' version go
alongside in the arch sub-directory?]


wrt to drem, it is man'd under RH linux but apparently none of the BSDs nor
plan9. Curiously the linux pages says it appeared in 4.3

should I PR a drem.3 ?


wrt to matherr.
That function was apparently part of 7th ed (Harbison & Steele mention
SysV). It's inclusion in ANSI C was considered but rejected, see p81 of
rationale. Partly because it potentially requires the math library to be
reentrant. That might be a worthy goal, but ANSI weren't going to require
reentrancy of conforming implementations. There are about two dozen .Xr to
matherr in man3, but they've all been commented out.

Can that symbol be removed from libm ?

from a quick grep, it only appears referred to from k_standard.c, but that
could be macrod out since s_matherr.c looks gutted. The only thing
preventing the removal of matherr, is third-party code which may use it.
That may be an issue if it was part of SysV. Since our version appears
dysfunctional anyway, I guess the proper thing to do is add a compiler
warning, a la gets(3). Maybe a matherr.3 describing it as deprecated needs
to be added for consultation by a person seeing a compiler/linker msg.

comments ?


Danny Thomas