The answer you can have the same source code and compile with gcc, but only cake is implementing the checks at this moment.
The have the same source code compiling in any compiler a header ownership.h is used to define owner etc as empty macro.
This strategy is used on cake source itself, that is checked with cake, but compiled with gcc msvc and clang.
Cake is a C23 front end, but it can also be used as a static analysis tool.
The qualifiers can be empty macros then the same code can be compiled with gcc , clang and the static analysis of ownership can be using cake.
Inside visual studio for instance, we can have on external tools
The main annotations are qualifiers (similar to const). C23 attributes were considered instead of qualifiers, but qualifiers have better integration with the type system. In any case, macros are used to be declared as empty when necessary.
The qualifiers and the rules can be applied to any compiler.
Something harder to specify (but not impossible) is the flow analysis.
Sample of rule for compilers.
int * owner a;
int * b;
a = b;
we cannot assign view to an owner object.
this kind of rule does not require flow analysis.
The C type system was extended with some new qualifiers. But only with flow analysis is possible to understand when variables goes out of scope or understand when the variables have been move before the end of scope.
As I said, this is a work in progress but I am already very optimistic.
To remove comments from source all you need is a tokenizer.
You don't need all the tokens, just the "preprocessor tokens". For instance
literal strings, ppnumbers ...
Then /comments/ can be replaced with 1 space and //comments by \n
Multi-line comments would need to be turned into multiple blank lines, but yes, thank you for pointing out that I've been over-thinking this. I will look into what is the path of least resistance for this tokenizer-based transformation.
My goal with the transpiler is not only the transpiler, although my front end had to be created differently of an normal compiler and preserve more tokens that could be discarded during the compilation. This also can be useful for a tool that does refactoring.. like renaming variables etc.. so in any case it it useful.
The new C23 language has a lot of features that makes your code not compile in previous C versions like attributes digit separators etc.. Someone may wants to create a new project in C23 and soon regret because the users of the code may need C99. This would be one use case, you can create a C23 code and have C99 versions of the same base code.
Unfortunately my transpiler is not "production ready" yet and I don't have IDE plugins etc.. that is required to make the tool more productive.
The other advantage, if we had a production ready transpiler with a IDE support etc.. it that we could use C23 and compile to C99 without having to wait for compilers like msvc to implements the standards.
Also some experimental features (like defer) can be used and you can distribute your code in standard C99. We have more freedom to use wherever we want and distribute a "readable" C99 code.
By the way most of the C transpilers or compilers generates C code only for immediate compilation. CFront was like that.
My transpiler have two modes one is for direct compilation and other is to distribute generated code.
> The new C23 language has a lot of features that makes your code not compile in previous C versions like attributes digit separators etc.. Someone may wants to create a new project in C23 and soon regret because the users of the code may need C99.
