Re: Drop Gnulib support for ecvt, fcvt, gcvt, getw, putw?

[Bruno Haible]

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