Eric Blake <eblake@xxxxxxxxxx> 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 _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
