Paul Eggert wrote: > I should have made it clearer that it was more to avoid confusion than > to optimize. ("Why does Gnulib mess with ecvt?" I wondered.)
Oh, I see. Yes, in stdlib_h.m4 we have unconditional invocations of AC_CHECK_DECLS_ONCE([ecvt]) AC_CHECK_DECLS_ONCE([fcvt]) AC_CHECK_DECLS_ONCE([gcvt]) Why are they there? It came when I added the Windows oldnames workaround in December 2020. - clang on Windows does not have the Windows oldnames library; on this platform, the redirects are always necessary. - On mingw, there would be an alternative workaround: add -loldnames in various LDFLAGS in the Makefiles. But it's simpler to treat this platform like clang on Windows. When I did that, I did it for all 50 functions at once. access chdir chmod close creat dup dup2 ecvt execl execle execlp execv execve execvp execvpe fcloseall fcvt fdopen fileno gcvt getcwd getpid getw isatty j0 j1 jn lfind lsearch lseek memccpy mkdir mktemp open putenv putw read rmdir strdup swab tempnam tzset umask unlink utime wcsdup write y0 y1 yn It would be possible to split this workaround into several modules: - one for 'close', one for 'dup', etc. - one for 'ecvt', one for 'fcvt', etc. - even for POSIX functions for which we don't have a module yet: 'chmod', 'fcloseall', 'fileno', 'umask' etc. But I fear that many packages won't request these up to 50 modules and thus, in practice, this portability problem will continue to exist for most packages. What I could reasonably do, though, is to handle the past-POSIX functions and the deprecated glibc functions differently: ecvt, fcvt, gcvt, mktemp, getw, putw. Since one can expect that few packages use these functions. Bruno