In my opinion, as a programmer who learned C when it was still in its infancy as a language, and who has used it in nearly every single project in 30+ years of professional development, what we need to do is not just teach the C LANGUAGE, but also the C RUNTIME, EXECUTION ENVIRONMENT, and .. most important of all .. the C COMPILER.

Each of these aspects of the "C ecosystem" needs to be well understood in order to be a productive, high-quality C developer. Its not enough to just type a bunch of stuff and then throw it at the compiler and see if it works - you have to understand what the compiler is doing with your language constructs and how this will be executed in the target execution environment.

So many times I've had to debug "professional C developers" who have no clue what the compiler is doing to their code, no idea what a TEXT SEGMENT is, absolutely zero responsibility for the HEAP, let alone runtime loading and linking. Its all just 'voodoo' behind the 'black box' of the compiler.

But even just having a basic understanding of these components can mean a huge difference in quality C code.

Another thing every C developer needs to know: how to debug code and read assembly language in the context of the operating/execution environment. You don't need to be able to WRITE assembly, but at least fire up the debugger and step through your program a few times to see how it behaves .. this can go a long way towards increasing a C developers understanding for what is happening and why its important to know all the other components. Too many times I've solved a major, delaying bug in a project by just re-ordering the linker commands or, even worse, cleaning up the linker commands to remove stuff that was glibly thrown at the wall by some other dev.

Also - all warnings are errors: no exceptions.