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

[Eric Blake]

On 02/09/2012 03:10 PM, Tim Landscheidt wrote:
> Hi,
> 
> 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.

> 
>   So is there a way to advise autoscan that it shouldn't
> suggest AC_FUNC_REALLOC?  Another (human) solution would of
> course be to add appropriate comments to configure.in and
> hope that they will be read, but I'd prefer something more
> robust.

Very hackish (and untested by me), but you could try to do this in your
configure.ac (or in an included .m4 file):

# This package promises to never use realloc(n, 0), so we don't
# want autoscan to suggest AC_FUNC_REALLOC, by redefining the
# problem
m4_define([AN_FUNCTION], [m4_if([$1], [realloc], [],
  [AN_OUTPUT([function], $@)])])

The idea here is that you redefine AN_FUNCTION (which is the magic that
makes autoscan actually suggest AC_FUNC_REALLOC in the first place, when
encountering an instance of 'realloc' in the scanned source code) to
something that is innocuous for 'realloc' while still being effective
for other suggested fixes.

-- 
Eric Blake   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature