But ISO does not explicitly say anything like "it is ok to aggressively rewrite programs...". ISO C says, "xy is defined and z is not defined in the standard and then an implementation is free to do whatever this wants". Note this is generally how standards works. You put them blame on ISO to give implementers the freedom, but not on the implementors to exploit this aggressively. Why do programmers still rush to the compilers that exploit this the most instead of choosing other ones? Why do they not complain more? Unfortunately, the effect of blaming ISO has exactly the opposite of what you may want to achieve. It deflects the criticism from the ones who do the decisions to ISO who can only harmonize behavior but does not really have the power to force implementors to do anything, as the realloc story shows. Even worse, this criticism weakens ISO even more, so we will become even less likely that we will be able to fix things using the limited de-facto power a standard has.
back
1 comments
No, it is definitely ISO C (and C++) fault [1]. Without guidance of what's acceptable behaviour and what isn't, DWIM and "please don't break my code" is not a spec. Consider type punning via enum, which is still UB in c++ while explicitly supported by most implementations. Most users are wary of making use of it because of possible, if only theoretical, portability problems. Generally provenance, aliasing and the basic memory model are a mess and need a more rigorous underpinning after having been patched during the years with sometimes conflicting wordings.
Compare to the concurrent memory model: while DRF-SC still has a plenty of UB, it is at least possible for a competent programmer to figure out the correctness of their code.
I certainly do not believe that is realistic to stamp out all UB from C and C++ (at least while pretending that the resulting languages have anything to do with the original ones), but there is a lot that the standard could do to try to limit the most egregious cases, possibly providing different levels of conformance (like it is done for floats and IEE754).
[1] of course implementors are part of the committee so they are not blameless.
I agree about the state of many things as you say and especially the point about more rigorous underpinning. But the flow of innovation and progress is not meant to come from ISO and flow to the compilers, the process is designed the other way round: Compilers implement things and ISO integrates this into the standard to avoid divergence. An ISO committee neither has the power nor resources to do what you want, and it is also not meant to work this way (we try nevertheless). But ideally, compilers vendors would need to work on fixing all these things and then ISO could simply standardize it. But for this, one would need to put pressure onto compiler vendors to actively work on those problems, and not blame ISO for not doing things it wasn't designed to do.
Oh, well, it seems I presented a very close example to what (I assume is) you raised in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104800 so this is nothing new for you.
I don't know how constraining is this more restrictive implementation of the standard is, but certainly it will help with maintaining a bit of sanity.