Eric Blake ebl...@redhat.com wrote:
for background, I'm looking at tackling a bug
(URI:https://sourceforge.net/tracker/?func=detailaid=1899047group_id=97492atid=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
I wrote:
for background, I'm looking at tackling a bug
(URI:https://sourceforge.net/tracker/?func=detailaid=1899047group_id=97492atid=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
On Mon, 20 Feb 2012, Tim Landscheidt wrote:
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.
No
On 02/20/2012 10:01 AM, Bob Friesenhahn wrote:
My proposal is to never run autoscan.
That's what *I* do.
But if you really want to run it, I suppose you can fool it, e.g.,:
q = realloc /* Pacify autoscan, since 'newsize' can't be zero. */ (p,
newsize);
Ouch! Now I'd better go hide under
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=detailaid=1899047group_id=97492atid=618177)
with flex's build system that seems to stem from the use of
AC_FUNC_REALLOC in configure.in without
Eric Blake ebl...@redhat.com writes:
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
