Re: [Tinycc-devel] Extension to C language

[Jared Maddox]

> Date: Wed, 30 May 2012 05:53:04 +0000
> From: Paulo Henrique Torrens <address@hidden>
> To: <address@hidden>
> Subject: Re: [Tinycc-devel] Extension to C language
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset="iso-8859-1"
>

>> Overloading requires decorated names, it's a both/neither type of> thing.
> No, they don't. C11's _Generic can be used... :)
>

To the best of my knowledge, C11's Generics are strictly a
preprocessor feature. This is required in order to maintain
compatibility with already existing C code & compilers, which expect
specific function names to accept specific argument sets. Generics
could presumably make it easier to deal with the multiple argument
sets required for overloading, but the overloading itself would
inherently require either Decorated Names or Dynamic Dispatch, and I'm
not certain that Dynamic Dispatch should be considered a valid way of
implementing Operator Overloading in a low-level language like C. It's
an implementation thing.


>> <snip>

> 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...

Yes, it's also mature & famous enough to turn it's nose up at
extensions, 'mature & famous' is a two-way street. I, for one, still
support a Extended C compiler as an additional compiler in the TCC
ecosystem, with the TCC C compiler mostly avoiding 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.

Consider: someone places the __attribute__((__cleanup__)) syntax on
the definition of a 'test_struct' struct in A.c. However, they forget
that they wrote 'struct test_struct;' in B.c, and thus fail to add the
__attribute__((__cleanup__)) syntax there. What's the behavior? Ths is
certainly a bad practice, but there's no reason to make it potentially
dangerous just for the sake of an extension that would be better
implemented with an ADDITIONAL compiler.


> Date: Thu, 31 May 2012 22:33:29 +0200
> From: grischka <address@hidden>
> To: address@hidden
> Subject: Re: [Tinycc-devel] Extension to C language
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> grischka wrote:
>> I tend to agree here with what Christian Jullien wrote:
>>
>>> I?m however against any C extensions that has no roots in C standard.
> [...]
>
> I wouldn't however mind at all an extension to TinyCC that allows to
> add language extensions as some sort of plugins.  If someone wants
> to undertake that s/he has my okay, even if it is just because I have
> no idea how it could be done.
>
> --- grischka
>

Since you know the code base better than I do, how practical would it
be to have a callback slot for the various locations where types can
be declared (typedef, struct, union), and how much info might said
callback be able to find? There's probably other feature sets to
target, but that's the first to come to mind.


As separate extension thoughts:

1) is there a TCC Make? I haven't found any sign of one, but I might
be overlooking it. If there isn't one then I might try my hand at
implementing one. I'm thinking a max of 255 rules, max 255 variables
(including the ones local to targets), max post-expansion command
length of 255 characters (seeing a pattern?), and some GNUish 'if'
statements. Thoughts? Would the -run switch for this need to switch to
internal-only commands (in case of e.g. tcc-boot)?

2) How about preprocessor extensions? I've thought about two types of
loops (for code generation purposes, e.g. for switches):

i) a count (repeats it's contents n times, with internal access
counters that specify the distance from both the begining & the end)
and

ii) an iterate (works similarly to template< typename W, typename X,
typename Y, typename... Z > class do_something< W, X, Y, Z... > :
public do_something< Z... >;, repeating the contents until all
arguments are used up, possibly with alternative contents for when
there aren't enough arguments left for the primary contents)

both written in the "if else endif" style, where there's a particular
preprocessor command that marks the end of the loop (as opposed to
define style, where you have to stick delimiters at the end of all
lines). They would both use the same namespace as defines, since
trying to provide an alternative one probably wouldn't go well. They'd
probably be named __count and __iterate (though I'm open to better
names), to put them into the implementation-reserved namespace.
Thoughts?