3 ms·

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 s

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.

uecker 2y ago
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.
- gpderetta 2y ago
  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 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.

uecker 2y ago

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.

gpderetta 2y ago
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 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.