I was wondering...

How practical it would be to grab Clang source code and modify it to make C programming a little bit different, like, for example, make functions static by default, or make variables declaration const by default, or make them be always 0 initialized but add a keyword like "undefined" or "---" (as in Jai) to don't initialize them to 0, between other simple things that would make it more similar to what modern languages are doing, but still beeing C as we all know how to program. Maybe it would be simpler than learning a hole new language? May not? Maybe just a tool that makes this kind of things would be better? I mean, I don't actualy know how practical it is to make, kind of, our own simple extension to C just by modifying a compiler source code. Never saw Clang source code, but I guess it is huge.

Well, just dreaming a little bit here, but... what are you thinking?

It is practical, but it will require understanding large parts of clang. I have done some custom attribute stuff in clang, and it worked fine.
The big annoying part will be keeping your modifications up to date. That's almost a full time job. Because it is unlikely your changes will be accepted upstream, so you will always need to rebase them on top of latest code.

Btw clang already now can initialize variables to 0 by default. There is special argument for that: "-ftrivial-auto-var-init=zero -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang". And to leave variables undefined there's attribute __attribute__((uninitialized));
See https://reviews.llvm.org/D54604 for more details.

mmozeiko
The big annoying part will be keeping your modifications up to date.

By this you mean that newest versions of Clang can make my modifications no longer working? Don't know how often this would happen, but if that's the case I think I wouldn't try to keep it up-to-date with every Clang release, maybe...

Now I got curious, I will to try it soon.

mmozeiko
Btw clang already now can initialize variables to 0 by default.

Oh! Didn't know about this, that's very handy. Thanks for the tip! I will try it out.

Deep modifications will have to be patched when the compiler gets updated or replaced, so I would insert my modifications as an additional preprocessor before compilation starts. Then the same preprocessor can be slapped over other compilers by generating new files when an operating system or library demands a specific compiler. Basic things like changing "" into U"" only requires a short module of tokenization to make UTF-32 into the default literal type.