Re: Playing with autoscan 2.54 on the Coreutils

[Paul Eggert]

> From: Akim Demaille <address@hidden>
> Date: 18 Sep 2002 09:45:48 +0200

> | > configure.ac: warning: missing AC_CHECK_FUNCS([dcgettext]) wanted by: 
> src/ls.c:1666
> | 
> | Is such a test needed?  If dcgettext is not a no-op, then we're using
> | a sufficiently new version of GNU gettext, which always has dcgettext.
> 
> I agree the test is probably not needed.  As a matter of fact, it is
> the whole lib/autoscan directory that needs an overhaul.  It's been
> too long I worked only on Autoconf, and not on a real C project that
> is very demanding on portability issues, so I don't feel I am
> competent to modernize these files :(
> 
> In the present case, should we
> 
> 1. have autoscan forget about dcgettext
> 2. have autoscan suggest AM_GNU_GETTEXT on dcgettext etc?

The latter sounds more reasonable from a C point of view.  It might
require some hacking on AM_GNU_GETTEXT, but let's try it and see what
happens.

> We extend autoscan with a means to say `deprecate function, do not use
> it'.

Sounds like a good idea.  I would put the inherently unsafe functions
like gets into this camp, too.


> | > configure.ac: warning: missing AC_CHECK_FUNCS([mkdir]) wanted by: 
> src/cp.c:432
> | > 
> | > I don't know what to do here.
> | 
> | Perhaps we need a way to tell Autoscan, "This program assumes that
> | mkdir() works; don't bug me about it." 
> 
> Well, it spells `AC_CHECK_FUNCS([mkdir])' :)
> 
> 
> | Or better yet, modify Autoscan to assume that mkdir() works by
> | default, so that people don't have to worry about it.  The existence
> | of mkdir() is a safe assumption for GNU apps these days.
> 
> I'm not sure I understand what you mean by `modify Autoscan to assume
> that mkdir() works by default': autoscan has a list of suspicious
> functions, not a list of sane functions.  So are you suggesting that
> we ought to remove `mkdir' from the suspicious functions?

Yes.  There are still a few embedded environments these days where
mkdir does not work (and indeed, there are no directories!) but those
folks are outside the intended audience.

> | > configure.ac: warning: missing AC_CHECK_FUNCS([pow]) wanted by: 
> lib/strtod.c:172
> | > 
> | > Is the non portability of pow obsolete?
> | 
> | "pow" was in 7th Edition Unix (1979).  I suppose some systems may lack
> | it (e.g. because they lack floating point) but I wouldn't worry about
> | them unless it comes up as a real problem.
> 
> :(  I thought the problem was only related to libm vs. libc.

OK, in that case that problem still remains, but surely it's not
addressed properly by AC_CHECK_FUNCS([pow]).  To fix that one must
append -lm on hosts when needed, e.g., `AC_CHECK_LIB(m, pow)'.
Unfortunately AC_FUNC_STRTOD already does something similar to
`AC_CHECK_LIB(m, pow)', but not equivalent; so this is a murky area.