[Tinycc-devel] glibc's <alloca.h> undefines alloca of TCC's <stddef.h>

[Kalle Olavi Niemitalo]

TCC 0.9.24 on i386 defines alloca as a macro in <stddef.h>.
However, it does not provide an <alloca.h>, so if the program
does #include <alloca.h>, then /usr/include/alloca.h installed by
glibc gets used, and it undefines the alloca macro and declares
alloca as a function instead; because TCC's function is actually
called _alloca rather than alloca, a link error results.  Worse,
glibc's <stdlib.h> and <regexp.h> also can #include <alloca.h>,
so we cannot simply avoid #include <alloca.h> in the program
itself.

#define _GNU_SOURCE
#include <stddef.h>
#include <stdlib.h>
int main(void)
{
        void *p = alloca(42);  /* tcc: undefined symbol 'alloca' */
        return 0;
}

To let ELinks use alloca() of TCC, it has been proposed that
ELinks should #define _ALLOCA_H before it includes any system
headers.  This would have the effect of making glibc's <alloca.h>
a no-op, so that the alloca macro in TCC's <stddef.h> would
remain defined.  However, that solution relies on an undocumented
aspect of glibc, so I am not entirely happy with it.

Could you add an alloca.h file to TCC, move the macro from
stddef.h to alloca.h, and change the preprocessor to look in
TCC's private include directory before it looks in /usr/include,
at least when <alloca.h> is requested?  This would also result in
better conformance to the C standard; <stddef.h> is not supposed
to define any macro called alloca.

Alternatively, I suppose you could rename _alloca() to alloca(),
so that it would actually be compatible with the declaration in
glibc's <alloca.h>, and the macro in stddef.h would not be needed.
That might however cause other problems if a program wants to
define a function called alloca that does something else.

pgpowr2ll4yGU.pgp
Description: PGP signature