Intrinsics are C language extensions outside the standard, but they are still an integral part of the "C language" that a specific compiler implements. In practice it really doesn't make much sense to separate the "standard C parts" and the "non-standard language extension" of a specific compiler.
The point is in reference to flohofwoe's earlier comment which stated "it's still fairly straightforward to map C statements to CPU instructions.". By pointing out the existence of vectorized instructions, which are entirely absent from the C standard, pjmlp was making an argument by counter-example. That while you can map C statements to CPU instructions, most compilers typically don't apply such a 1-1 mapping.
The seeming non-sequitur referring to the ISO C standard was because flohofwoe responded to the rhetorical question as if it were a normal question, leading pjmlp to restate the rhetorical question in a stronger form.
The point is that C is very far away from being a "portable assembly" for any kind of modern processor. For the PDP-11 and other processors from that era, there was indeed some pretty simple 1:1 mapping between C instructions and their assembly. This has not been true for decades.
The C standard only matters for compiler writers. What matters for compiler users is what specific compilers actually implement (and it's pretty much impossible to write a non-trivial C program which is 100% standard compliant, the Windows headers alone are full of MSVC idiosyncrasies).
> The C standard only matters for compiler writers.
There's two types of projects: those that are so big that any compiler writer will test against them to guard against Hyrum's Law, and those that are not. The former have no need for the C standard, as compiler writers would be loathe to break compatibility with it. The latter have a strong need for the C standard, as anything outside the C standard may be broken unknowingly by compiler writers.
> What matters for compiler users is what specific compilers actually implement
What matters for me is the likelihood that a compiler upgrade will break my code. If I stay within the standard, then any such breakage is a bug. If I stray outside the standard, then all I know is that this specific compiler, in this specific context, on this specific machine, for this specific compilation, has produced some machine code.
My home projects are not so large that gcc/clang/msvc authors would test their upgrades against my project, so the bounds of the standard are the limits that I can trust.
> the Windows headers alone are full of MSVC idiosyncrasies
I'd put the Windows headers in the category of sufficiently-large projects that compiler writers would test against them, rather than the other way around.
> My home projects are not so large that gcc/clang/msvc authors would test their upgrades against my project, so the bounds of the standard are the limits that I can trust.
You'll need to check your code against each new compiler release you want to support anyway, because each release adds a shitton of new warnings which are also not covered by the C standard but should be fixed nonetheless.
Absolutely, and it's really fantastic seeing how many bugs get caught from the new warnings. However, the effort required to check warnings is far, far less than the effort required to validate the assembly output, and so I think the point still stands.
