Re: autoscan: Advising that AC_FUNC_REALLOC is not The Right Thing (TM)

[Tim Landscheidt]

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