bug-gnulib
[Top][All Lists]
Advanced

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

Re: AC_FUNC_STRTOD


From: Bruno Haible
Subject: Re: AC_FUNC_STRTOD
Date: Mon, 14 Jun 2010 21:56:03 +0200
User-agent: KMail/1.9.9

Hi Eric,

> >     With two old old old tests and no reasonable cross-compiling behaviour I
> >     would say that the best thing to do is to move these two blocks of C 
> > code
> >     into gl_FUNC_STRTOD's test, and stop using AC_FUNC_STRTOD. Then the
> >     autoconf documentation can mark this macro obsolescent, and on the 
> > gnulib
> >     side this test runs one program, not two, and we have full control over
> >     the cross-compilation behaviour.
> 
> Or even better, why not push those two tests upstream into autoconf,
> then have gnulib override AC_FUNC_STRTOD if it detects older autoconf,
> so that everyone using upstream AC_FUNC_STRTOD can reliably detect these
> same bugs?

I don't think this would be better. The gnulib development of the last 7 years
has shown that the autoconf macro that detects bugs of a system function and
the replacement code that contains the workarounds to these bugs belong
together and are best maintained together. It makes no sense to me to put the
two files into different projects - autoconf and gnulib.

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

Bruno



reply via email to

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