3 ms·

What's the behavior of this piece of code according to the spec? You can choose any C/C++ spec: void f() { char x[100]; gets(x); }

gpderetta 2y ago
The key here is the meaning of "ignoring" in "ignoring the situation completely with unpredictable results". Most programmers (and pretty much all compiler writers) interpret it as meaning that the compiler can assume it can't happen (ignore the possibility) and translate accordingly. Some, like mpweiher interpret it as meaning that the compiler must implement a trivial (but somehow unspecified) translation to the underlying hardware and let the behavior be what the hardware provides. edit: We went through this many many times.
- tialaramex 2y ago
  This craziness (a belief that if you don't specify what something means it must have some "obvious" behaviour that is coincidentally always whatever the programmer wanted) is endemic in C and C++ communities. Right now, notionally serious people are making the case that C++ should enshrine the "bag-of-bits" model of pointers which is exactly this sort of stupidity. At first it looks like they want pointers are addresses which is kinda dumb but whatever, and you keep reading and they're like aha, also I should be able to dereference my bag-of-bits and have that work too... Full blown Provenance Via Integers, expect to spend the next forty years trying to specify how any of the optimisations you rely on can survive the resulting tangle, say hi to anybody who wanted Consume ordering and is still waiting.
  - marssaxman 2y ago
    > This craziness (a belief that if you don't specify what something means it must have some "obvious" behaviour that is coincidentally always whatever the programmer wanted) is endemic in C and C++ communities. That belief is endemic because that is the way things actually worked for many years! Compilers used to give us the obvious behavior, because they weren't smart enough to outfox us by doing anything else, because the CPUs we used were not fast enough to let them do the kinds of comprehensive optimization analyses which are now routine.
    - gpderetta 2y ago
      No. The reality is that every new generation of programmers is completely comfortable with optimizations that existed before it started programming and surprised by optimizations added after that. Today we take for granted SSA, extensive interprocedural optimizations, value-range propagation and LTO. Before that was aggressive inlining and SRA; before that was smart register allocation and stack optimizations. Even before that it was instruction scheduling. Each one of these optimizations have broken someone's code.
- mpweiher 2y ago
  The idea that "undefined behavior can't happen" is ludicrous, because it happens all the time. The idea that most programmers also believe this nonsense is entirely unsupported. It is very popular in a small range of very influential companies.

gpderetta 2y ago

The key here is the meaning of "ignoring" in "ignoring the situation completely with unpredictable results". Most programmers (and pretty much all compiler writers) interpret it as meaning that the compiler can assume it can't happen (ignore the possibility) and translate accordingly. Some, like mpweiher interpret it as meaning that the compiler must implement a trivial (but somehow unspecified) translation to the underlying hardware and let the behavior be what the hardware provides. edit: We went through this many many times.

tialaramex 2y ago
This craziness (a belief that if you don't specify what something means it must have some "obvious" behaviour that is coincidentally always whatever the programmer wanted) is endemic in C and C++ communities. Right now, notionally serious people are making the case that C++ should enshrine the "bag-of-bits" model of pointers which is exactly this sort of stupidity. At first it looks like they want pointers are addresses which is kinda dumb but whatever, and you keep reading and they're like aha, also I should be able to dereference my bag-of-bits and have that work too... Full blown Provenance Via Integers, expect to spend the next forty years trying to specify how any of the optimisations you rely on can survive the resulting tangle, say hi to anybody who wanted Consume ordering and is still waiting.
- marssaxman 2y ago
  > This craziness (a belief that if you don't specify what something means it must have some "obvious" behaviour that is coincidentally always whatever the programmer wanted) is endemic in C and C++ communities. That belief is endemic because that is the way things actually worked for many years! Compilers used to give us the obvious behavior, because they weren't smart enough to outfox us by doing anything else, because the CPUs we used were not fast enough to let them do the kinds of comprehensive optimization analyses which are now routine.
  - gpderetta 2y ago
    No. The reality is that every new generation of programmers is completely comfortable with optimizations that existed before it started programming and surprised by optimizations added after that. Today we take for granted SSA, extensive interprocedural optimizations, value-range propagation and LTO. Before that was aggressive inlining and SRA; before that was smart register allocation and stack optimizations. Even before that it was instruction scheduling. Each one of these optimizations have broken someone's code.
mpweiher 2y ago
The idea that "undefined behavior can't happen" is ludicrous, because it happens all the time. The idea that most programmers also believe this nonsense is entirely unsupported. It is very popular in a small range of very influential companies.