[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: autoscan: Advising that AC_FUNC_REALLOC is not The Right Thing (TM)
From: |
Tim Landscheidt |
Subject: |
Re: autoscan: Advising that AC_FUNC_REALLOC is not The Right Thing (TM) |
Date: |
Wed, 22 Feb 2012 00:33:30 +0000 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) |
Eric Blake <address@hidden> wrote:
>> for background, I'm looking at tackling a bug
>> (<URI:https://sourceforge.net/tracker/?func=detail&aid=1899047&group_id=97492&atid=618177>)
>> with flex's build system that seems to stem from the use of
>> AC_FUNC_REALLOC in configure.in without including gnulib's
>> (or another) implementation. I believe this can be fixed by
>> simply omitting AC_FUNC_REALLOC (on the premise that
>> realloc(p, 0) is never used).
>> The macro was originally added to configure.in on the sug-
>> gestion of autoscan which basically means that in a few
>> years some well-meaning developer will probably re-run auto-
>> scan, re-add the macro and the bug will re-appear.
> Autoscan is primarily designed as a once-only program, only done when
> first converting to autotools, and not something you repeatedly run (and
> it shows, due to the lack of attention given to autoscan - these days,
> the ratio of projects converting to autoconf for the first time compared
> to the projects already using autoconf is dropping, compared to when
> autoscan was first implemented). I personally haven't used autoscan.
> [...]
Thanks for the hack and also the others for their opinions.
There seems to be a consensus that autoscan shouldn't be
used for maintenance. Yet the manual advertizes exactly
that; and even if you use it on a new project (again as re-
commended by the manual), it will suggest for example
AC_FUNC_REALLOC without any further explanation. In
autoscan.log, it will just state very matter-of-factly:
| autoscan: warning: missing AC_FUNC_REALLOC wanted by:
| main.c:123
So the more I think about it, I would consider autoscan's
current behaviour a bug that just doesn't surface in glibc/
Gnulib environments. Hmmm.
Tim