Re: update to configure bug in Bison 1.31

[Akim Demaille]

>>>>> "Tony" == Tony Leneis <address@hidden> writes:

Tony>   I should have proof read my e-mail and also tested it...  The
Tony> function should have been named rpl_malloc(), and it has to
Tony> exactly match the prototype for malloc() (since the define in
Tony> confdefs.h is apparently done before stdlib.h is included.)

Tony>   Perhaps the simplest solution is to just add "#undef malloc"
Tony> to the beginning of the mmap() test program.  That works fine on
Tony> Tru64 Unix, though I suppose it could potentially be a problem
Tony> for other systems.

Tony>   Again, the problem was that when the test for a working
Tony> malloc() fails, configure adds a line to confdefs.h that
Tony> redefines malloc to be rpl_malloc.  Subsequently, any remaining
Tony> test programs that use malloc() and include confdefs.h fail.  In
Tony> bison's case, the mmap() test always indicates that mmap()
Tony> doesn't exist or doesn't work, because the linker can't find a
Tony> symbol for rpl_malloc.

Thanks, this is an Autoconf problem, indeed.  Given that the risk to
have this problem with other functions, and especially given that the
risk for novices is even higher to face this problem, I'd like to have
Jim's and Paul's opinion here.

In any case, the easiest is to do exactly what you suggest: have the
mmap test be adjusted.

The safest is probably to introduce in Autoconf the concept of
rpl_func, and adjust the tests accordingly.  But I'm not sure how yet.