Re: [Tinycc-devel] Extension to C language

[Paulo Henrique Torrens]

> I don't think it would necessarily need to be completely separate from
> TCC, nor a complete fork. I think that having a "Extended C" directory
> + a few patches for individual TCC-proper files is all that would
> actually be needed

This could be added as an extra flag to the ./configure script... 

> Overloading requires decorated names, it's a both/neither type of
> thing.

No, they don't. C11's _Generic can be used... :)

> Incidentally, if you actually go for the objects, I would argue
> against strict C++ style (even if a reduced subset). Better that you
> do something that can be duplicated in pure C and doesn't have as much
> mess, especially since then interfacing to it from C++ would just
> involve wrappers (regardless of C++ compiler).

Let me suggest something.

I don't know what you guys think, but in my compiler project, I've made the C and C++ frontends separately, instead of mixing it as GCC/CLang does. In the C compiler, I've added a compiler flag -fsugar, to enable "syntactic sugar extensions", including my tracked variable thing. This flag is needed to use the feature, which can be implemented in a pure C compiler, as it was just a syntactic sugar thing, the compiler generates some function calls (mostly inlined). I didn't use anything that couldn't be made in an ANSI/ISO C environment, as static constructors in C++. This was made in the spirit that Vala makes its code.

There is a runtime library which ships with the compiler that contain those functions, if anyone has to mix compilers.

TCC has some GNU extensions, but I think you all would agree that it is already mature and "famous" enough to contain some of it's own extensions... again, I am not "asking" for it, it makes no difference for me at all, but as it seems that there are some people interested, here are my suggestions.

A good start would be, as TCC already accepts __attribute__, to port the __attribute__((__cleanup__)) syntax from GCC, and extending it to types. On GCC, you can use it to set cleanup code for local variables, but it is a variable attribute... using it as a type attribute, it could help whoever might need such facility.

> And that's assuming that Grishka/Thomas/etc. want such a thing
> definitively outside of the main TCC project. Grishka/Thomas, what
> expectations do you guys have on that front?

Yes, it would be nice to get your opinion on that... also on the reference/tracked types issue (which was the start of this topic), because I already have the patches.

I remembered something now. I have implemented the decimal floating point types (_Decimal32, _Decimal64, _Decimal128, http://en.wikipedia.org/wiki/IEEE_754-2008, http://gcc.gnu.org/onlinedocs/gcc-4.2.4/gcc/Decimal-Float.html) and the fixed point types (_Accum and _Fract, http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf, http://gcc.gnu.org/wiki/FixedPointArithmetic) on my C compiler (although they are an ISO extension and of the embedded C standard)... since I plan on encouraging the use of TCC for bootstrap, I volunteer to implement those on TCC if Grishka/Thomas/etc think it would be useful. :)