No, what I said is that compilers shouldn't care about libraries that are not part of the actual programming language as per the thread you are talking about. I can make my own strcpy and I don't want the compiler to police me. So big NO to kcc.
Also what I said also is that if I know the instruction set of the targeted processor, and it can do overlapping memory copies with expected behavior and I would take advantage of that on small MCU.
Also what I said is that I rather program in Assembly because C does a poor job on MCU's.
On large projects tailored to big systems and with a lot of people collaborating, I'll go to safer standards.
I also said that C belongs to kernels, but I wouldn't do overlapping functions there.
If I know that for a particular MCU the memcpy listing behaves like I want it to behave then I might use the memcpy function, but most likely I would use assembly and if I have to support other micros then I will use macros. But only when a program doesn't fit the chip.
There are many aspects to programming. For example displaying a hex number from a 4 line input. I approached it with boolean logic using CPLD like features in a chip, someone else mentioned using an LUT. But using my method I could use the same chip to drive three 7 segment displays, using the "simpler" LUT approach only allowed for two 7 segment displays. So I saved one 3rd of the cost with my more complicated approach.
There are fewer and fewer kids out of University that know assembly, "Because you don't need it anymore", compilers are crap on what they do and waste a bunch of resources, normally nobody cares because we just throw more resources to it, but on MCU's you just can't do that.
More than your concern with C or C++ or standards I would be more worried about the lack of programmers to embrace functional programming. Multicore everywhere and no program can take advantage of the latest hardware advances. Learn at least some Erlang. I might do you some good.
Cloud computing same thing. C is old, so it's C++ and the funny thing is that Erlang is as old but way different. F# go for it, even Smaltalk, Haskell fine, whatever. C as it is is going to loose it's ground soon because the code will be inefficient in the current hardware.
The thing is, that I do keep up with current trends in both software and hardware, so your thought on what I can do or I can't do are pretty much irrelevant. I will keep on doing what I'm doing because I know myself better than you do, and I know where things are going as well.
One thing is for sure, in programming you just can't stop learning or you'll loose your edge, but the same is true everywhere.