Re: Drop Gnulib support for ecvt, fcvt, gcvt, getw, putw?
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
Re: Drop Gnulib support for ecvt, fcvt, gcvt, getw, putw?
On 6/12/22 21:54, Bruno Haible wrote:
Paul Eggert wrote:
The functions ecvt, fcvt, gcvt, getw, putw are no longer in POSIX and
the glibc manual pretty much recommends against them. How about if we
drop Gnulib support for them? This would speed up 'configure' a bit,
among other things. As far as I know nobody uses them.
I think this is a wrong axis of optimization.
I should have made it clearer that it was more to avoid confusion than
to optimize. ("Why does Gnulib mess with ecvt?" I wondered.)
Your other optimization suggestions look reasonable, if someone has the
time.
For more-drastic performance improvements we could use improvements to
the shell. I'll send a followup email about this.
Re: Drop Gnulib support for ecvt, fcvt, gcvt, getw, putw?
Paul Eggert wrote: > The functions ecvt, fcvt, gcvt, getw, putw are no longer in POSIX and > the glibc manual pretty much recommends against them. How about if we > drop Gnulib support for them? This would speed up 'configure' a bit, > among other things. As far as I know nobody uses them. I think this is a wrong axis of optimization. If we start with these functions - which may speed up configure by maybe 1% - , next will be the question about other "rarely" used functions. And in order to reach an optimization of 20%, you need to remove a *lot* of them. So many of them, that we'll eventually break packages that use Gnulib and practically defeat the purpose of porting POSIX to all platforms. It is more promising IMO to look for other axes of optimizations: (B) Combine multiple AC_CHECK_DECLS_ONCE or gl_WARN_ON_USE_PREPARE for different functions into a single compiler invocation, at least for the common case when GCC is used. (C) Remove workarounds for specific platforms. I this it by now we can consider OSF/1, IRIX, and HP-UX as museum systems. (C) needs to be done with care, because it can easily introduce regressions on other, still used, systems. Therefore my favourite would be (B). Bruno
Re: Drop Gnulib support for ecvt, fcvt, gcvt, getw, putw?
On Sun, Jun 12, 2022, 1:11 PM Paul Eggert wrote: > The functions ecvt, fcvt, gcvt, getw, putw are no longer in POSIX and > the glibc manual pretty much recommends against them. How about if we > drop Gnulib support for them? This would speed up 'configure' a bit, > among other things. As far as I know nobody uses them. > Sounds good to me. >
