Hello Bruno,
Sorry for the delay.
* Bruno Haible wrote on Tue, Oct 23, 2007 at 01:08:54AM CEST:
> Ralf Wildenhues wrote:
> > on Tru64 4.0D I got this:
> >
> > | cc -DHAVE_CONFIG_H -DEXEEXT=\"\" -DEXEEXT=\"\" -DNO_XMALLOC -DEXEEXT=\"\"
> > -I. -I.. -I../../dummy-0/gllib -I../intl -ieee -g -c -o realloc.o
> > ../../dummy-0/gllib/realloc.c
> > | cc: Error: ../../dummy-0/gllib/realloc.c, line 56: In this statement, a
> > common type could not be determined for the 2nd and 3rd operands
> > ("malloc(...)" and "realloc(...)") of a conditional operator. (badcondit)
> > | result = (p == NULL ? malloc (n) : realloc (p, n));
> > | ------------^
> > | gmake[3]: *** [realloc.o] Error 1
> >
> > ... due to malloc being #defined
> > but not restored like realloc in realloc.c, there is a type mismatch,
> > as the rpl_malloc function is not declared.
>
> Thanks for the analysis. Your patch does two things:
>
> - You realized that when REALLOC_0_IS_NONNULL && ! MALLOC_0_IS_NONNULL
> the code is wrong because it may malloc(0).
Yes.
> A good point. Can you prepare
> a fix for this that is independent from the other issue?
I may be able to once I understand the following:
> - It does weird #undef games to get the malloc() declaration from the system.
> The problem is that malloc is already defined to rpl_malloc in config.h.
> This idiom comes from the times when we did the function replacements in
> config.h.
Well, it comes from the age-old interface of AC_FUNC_MALLOC (upon which
lots of non-gnulib code relies, BTW).
Are you suggesting that gnulib not use AC_FUNC_MALLOC, but use a copy of
its own that does not #define malloc to rpl_malloc? Isn't that
unnecessary code duplication? Sorry, I just fail to see what's weird
about it; esp. since it also requires gnulib users to not use
AC_FUNC_MALLOC, which the current scheme is robust against.
> Now we normally do them in the appropriate header file substitute,
> such as in stdlib.h. This has the advantage that we can first include the
> original <stdlib.h>, to get malloc()'s original function declaration, and
> then only we '#define malloc rpl_malloc' and provide a function declaration
> for rpl_malloc.
Well, but the way the malloc module works now, it, well, works. What's
better about the other way?
> The 'malloc-posix' module already uses this new idiom. Can you change the
> 'malloc' module to use the new idiom as well? This will fix this issue.
Thanks for enlightening me.
Cheers,
Ralf
