bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AC_FUNC_STRTOD


From: Eric Blake
Subject: Re: AC_FUNC_STRTOD
Date: Fri, 17 Sep 2010 10:03:31 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.9) Gecko/20100907 Fedora/3.1.3-1.fc13 Mnenhy/0.8.3 Thunderbird/3.1.3

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]