There is the TCC. Adapting that would probably be a faster path to a full featured C compiler on esp32 than building up my xcc700. This is more of an educational sandbox project.

I know, and there are chibicc, kefir, etc. .. and I have my own experimental C compiler.

I would love to see how you handle variably-modified types, the way I retrofitted them onto chibicc never felt quite right, and I've never seen another non-gcc/clang compiler fully support noplate's VM type patterns.

Maybe I fill find the time to clean it up and make it public. But did not find VM-types difficult to implement, the type just depends on some run-time value, so at the point in time where the size expression is evaluated, one stores the result in a hidden variable which the type refers to.

Looking forward to the release!

What I found troublesome were not really the caching of array count, but when and where should the side effect be represented in AST, for example this one: https://godbolt.org/z/rcT1d8WWe the puts() call is a side effect for automatic variable but completely ignored for static variable.

Yes, it is a bit of mess. We started to make this more precise in the C standard when those expression have to be evaluated, but there are still issues. And when this is involved extensions there are more issues. I think in this example, such initializer would not be allowed in ISO C. I also fixed many bugs in GCC .

What we need is safety improvements in C, we already have enough security exploits in the standard library, strings and arrays, no need for more, without fixing what is broken since 1979 (lint birth year).

I am looking forward to your contributions.

I have been contributing with C++ code since 1993, with bounded checked collection types in release code, and compiled managed languages since mid 2000's.

Even Dennis Ritchie and Ken Thompson themselves, went on with Alef, Limbo and Go.

I have been contributing by reducing my C, and C++ footprint on the planet, and security enforcement at various assignments.

These do not seem to be the safety improvements for C that you requested.

They do, by decreasing the dependency on C, and the lack of interest WG14 shows in improving C.

It is like gardening, slowly taking away all the paths bad weeds are still able to spoil the garden.

We might not remove all of them, however if they are only able to thrive on a little gardner corner surrouned by sand is already an improvement.

As I said before, insulting volunteers and also misrepresenting what is in the power of an ISO group of experts is bad style IMHO, but I also think you are misguided in thinking that moving away from C towards more complexity is good. My own IT security and sovereignty is more harmed than helped by this trend.

Volunteers follow a charter set up by ISO, The C Standard charter, and definitely WG14 has not had security on C for quite some time.

I recall for the audience, that enable secure programming, and enable functional safety are two of such goals.

Nonetheless, other than some UB improvements has been business as usual.

If it is insulting to point out what isn't being achieved, then so be it.

As for volunteers, my point regarding WG14 and WG21 is that compiler vendors are the ones that should be part of ISO, and if they don't see any value in that, maybe it is about time to ramp down the whole effort, and finally replace them.

The charter is not set by ISO. It also has security on it since C11 and was rewritten for C2Y with security also mentioned explicitly. Compiler vendors are active as part of ISO, but the reality is simply that the open-source compilers are also massively underfunded. It is the general maintenance problem that we now have everywhere in IT. One can argue that activities that are not of enough interest should be ramped down, but then the conclusion is that only new things have a right to exist, and everything has to be rewritten all the time because it has to be ramped down the moment industry loses interest and maintenance become a problem. Somehow I doubt this would be an improvement.