C development, like most languages, isn't really "taught" at all. You might have some teaching on the structure of the language and a basic getting started course on main(), but that's just the beginning. Everything from there up seems to be self-taught, either from the internet, code examples, or working it out from first principles.
There are a lot more risks in C than more recent languages. Koenig's book "C Traps And Pitfalls" https://www.amazon.co.uk/C-Traps-Pitfalls-Andrew-Koenig/dp/0... was extremely useful to me when I was learning the language (available at my local library!). I don't know if there's a more modern version that takes into account recent changes to the C standard.
I note that a lot of the time in embedded work you don't get to use the latest version of the standard because you're using a weird or obsolete toolchain that doesn't support it. Or architectures like PIC, where your stack is hardware limited to 8 levels and indirect addressing is inefficient.
I think a lot of the "pure C" people are disguised as electronics engineers - doing PCB design and microcontroller programming together.
There are a lot more risks in C than more recent languages. Koenig's book "C Traps And Pitfalls" https://www.amazon.co.uk/C-Traps-Pitfalls-Andrew-Koenig/dp/0... was extremely useful to me when I was learning the language (available at my local library!). I don't know if there's a more modern version that takes into account recent changes to the C standard.
I note that a lot of the time in embedded work you don't get to use the latest version of the standard because you're using a weird or obsolete toolchain that doesn't support it. Or architectures like PIC, where your stack is hardware limited to 8 levels and indirect addressing is inefficient.
I think a lot of the "pure C" people are disguised as electronics engineers - doing PCB design and microcontroller programming together.