• You don't control your ABI. For example, you can't reserve a register for error object return like Swift does.

• You don't control your stack and stack frames. You can't implement a segmented stack, for example.

• You have very limited options for unwinding. setjmp doesn't really cut it. You could leverage C++ exceptions or platform-specific things like SEH, but you can't design anything radically different.

• You can't have debug information fancier than #line and maybe reusing C++ name mangling. You can't make debuggers see your higher-level constructs and data as anything other than their lowering.

• You have very limited options for specifying pointer aliasing.

• If you don't want to inherit UB from C, you'll have to be very clever about using alternative constructs that don't cause UB while still compile to efficient code you wanted.

• If you mean standard C, not C with compiler extensions, then look at the whole list of non-standard intrinsics and built-ins for things C can't do.

If your source language has some construct that you want to express as state machines (e.g. async, CPS, pattern match compilation), and you want to compile the state machine as direct threaded code[0] (which involves fewer branches than a while-switch), then if you're compiling to C, you need computed gotos[1], which are non-standard.

[0]: https://en.wikipedia.org/wiki/Threaded_code#Direct_threading [1]: https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html

It's not only interesting, it's blatantly false.