[Tinycc-devel] stdarg.h overhaul (was: /usr/include/syslog.h:68: error: invalid type)

[Michael Matz]

Hello all,

On Wed, 15 Apr 2020, Michael Matz wrote:

> >  I would appreciate some help understanding this syslog.h "invalid
> >  type" problem. I don't quite get it :) FWIW that line references
> >  va_list which
>
> ... ah, oh, see?  :)  Hmm, so is TCC's stdarg.h really being included, 
> or is it picking up some other stdarg.h?

So, I've dusted off an old patch of mine that overhauls how TCC is doing 
stdarg.h support.  mob at 2f943902 has it.  In particular our own stdarg.h 
now looks like this:

-----
typedef __builtin_va_list va_list;
#define va_start __builtin_va_start
#define va_arg __builtin_va_arg
#define va_copy __builtin_va_copy
#define va_end __builtin_va_end
-----

(not much different from musl stdarg.h)

In other words, TCC now always defines __builtin_va_list, 
__builtin_va_start, __builtin_va_arg, __builtin_va_copy and 
__builtin_va_end.  The way it does so is unconventional but as 
identifiers with __builtin are purely for compiler implementations that 
shouldn't matter (see below).

I've tested this on glibc linux (x86-64, riscv64, arm64, armhf and i386), 
and on alpine linux x86-64 (i.e. a musl distro, my rootfs was a bit 
oldish, but still).

So, hmm, that might mean that TCC is now working a bit more out of the box 
for musl systems.  Lacking something like a MacOS rootfs/sandbox I can't 
verify if this also helps MacOS, it might make things better or worse, so 
I'd appreciate some testing there.  And all other testing as well of 
course.

For the curious: the way it's implemented is still partially via 
macros which are pre-loaded from a header named tcc_predefs.h before any 
other processing.  It is loaded unconditionally, and I'm using it simply 
to make the implementation of these builtins easier to maintain; for all 
intents and purposes these are now really built into tcc.  Programs can 
detect a difference to e.g. GCC by #ifdef testing of those identifiers, 
and if absolutely necessary that could also be disabled, but as programs 
really have no business in doing such hackery we should do that only when 
we have evidence that it's necessary.

Would be nice if you could check that on ulinux and libressl :)


Ciao,
Michael.