I would argue it's very easy to think one understands it. However I would wager most people who say they understand C don't really know many of the undefined behaviour cases and their implications.
In my experience it's only the language lawyers who actually know what to look out for, and there are damned few of them.
Which is stupid since undefined and unspecified behaviors are hugely important to how C and C++ are used in the field.
Is it really that fundamental if you can setup your project to throw warnings/errors, and even use static code analysis tools to flag those?
I'd argue that it's far worse to work on a project that's not setup to detect those errors than to expect that sort of issue to be handled at the recruiting level.
Why are they though? Should they be?
(But, I also totally concede that a language is inseparable from its std lib in reality)
It is a feature introduced by compiler writers who prize esoteric optimisations more than simplicity.
And it is not forbidden by the standard, though discouraged.
Use-after-free or double-free is undefined behavior.
Therefore a C implementation that provides malloc(3) should provide an implementation of free(3) that is a no-op and provide a garbage collector that actually frees the memory.
It's not an argument, it's an observation and statement of fact.
> Use-after-free or double-free is undefined behavior.
Yes.
> Therefore
Why therefore?
> a C implementation that provides malloc(3) should provide an implementation of free(3) that is a no-op and provide a garbage collector that actually frees the memory.
If you think so. It certainly doesn't follow from what I wrote. My point is that if you use a pointer after you freed the memory, you get whatever is in memory that the pointer points at on the machine the code is running on.
That is not a "weird and bizarre" implication, it is a plain and straightforward implication given how C is implemented on real machines. It is (obviously, I hope!) outside of the scope of the C standard to say what will be at that memory location at that point, and therefore it is UB.
And it being UB, "what you get" may also, for example, be a segfault because the library/OS have decided to unmap that memory. And again, that is also not "weird and bizarre", but perfectly straightforward.
¯\_(ツ)_/¯
It's an error even if it's undetectable by the compiler. I understand that nomenclature from few decades ago makes a distinction but nowadays we just call such thing an error.
How so? It is behavior left undefined in the C standard.
> It is a feature introduced by compiler writers who prize esoteric optimisations more than simplicity.
It's not the compiler writers who left the behaviour undefined, but the standard writers. If it was so clear what should be done (so all compiler writers should do it in one way) then why did they not define it?
> And it is not forbidden by the standard, though discouraged.
What do you mean it's not forbidden in the standard, it's undefined in the standard hence the name. Because of this you really should not rely on it, because the behavior could change.