Re: AC_FUNC_STRTOD

[Eric Blake]

On 06/14/2010 06:08 PM, Russ Allbery wrote:
> Bruno Haible<address@hidden>  writes:
>
> > At this point, it would be a good idea to mark all AC_FUNC_* macros that
> > request an AC_LIBOBJ replacement as obsolete and refer the user to Gnulib
> > for both the macro and the workaround code (and the documentation).
> > Except maybe AC_FUNC_MALLOC and AC_FUNC_REALLOC, because the replacement
> > code for them is so trivial that anyone can make it up himself.
> > The affected macros are:
> >    - AC_FUNC_ERROR_AT_LINE
> >    - AC_FUNC_GETLOADAVG
> >    - AC_FUNC_LSTAT_FOLLOWS_SLASHED_SYMLINK
> >    - AC_FUNC_MEMCMP
> >    - AC_FUNC_MKTIME
> >    - AC_FUNC_OBSTACK
> >    - AC_FUNC_STAT, AC_FUNC_LSTAT
> >    - AC_FUNC_STRTOD
> >    - AC_FUNC_STRNLEN
> >    - AC_REPLACE_FNMATCH
>
> This seems like a reasonable plan to me, but if you do this, the one
> additional request I have is to please retain somewhere in the Autoconf
> documentation a mention that these functions have known portability
> issues.  I think many people use the Autoconf manual as one input source
> (of several) of information about functions that may need portability work
> on platforms one doesn't have at hand when doing development, and I'd like
> to not lose that information.

Marking a macro obsolete in autoconf means that new code should not rely 
on it, but that the macro still exists and still does the same thing it 
used to do, so that old code that used it will continue to work.

Someday, we should probably actually patch autoconf to issue warnings 
for macros marked obsolete; we have the plumbing built in for that, with 
-Wobsolete, but haven't been using it lately.  I guess I should follow 
up with patches to add that warning in a few more cases.

> The one drawback of this is that this change will be frustrating for users
> of the Autoconf macros who were providing their own replacement
> implementations, since now they either have to write their own Autoconf
> macros as well or have to deal with importing of Autoconf macros from
> Gnulib, which is more complex than using macros that are part of Autoconf
> (particularly in keeping them up-to-date).

If you already had your own replacement implementation, it will continue 
to work. The people this affects most are those that want to use the 
macro, but have not yet written a replacement implementation - in that 
case, it is easier to point them to a completely working macro along 
with a replacement (gnulib), than it is to perpetually keep updating 
autoconf every time gnulib improves its detection.

--
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org