4 ms·

Correct me if I'm wrong, but I think you're misunderstanding what they're saying. They're not saying that undefined behavior can be ignored because it "probably

Correct me if I'm wrong, but I think you're misunderstanding what they're saying. They're not saying that undefined behavior can be ignored because it "probably won't happen" or something like that. They're saying that undefined behavior is everywhere in the C standard and that this fact is commonly exploited for the purposes of optimization. For example, signed integer overflow is undefined behavior which allows the compiler to avoid extra sign extensions when indexing in a loop. Would you want a warning to be emitted at compile time every single time you write "for (int i = 0...)"? I'm sure that would actually end up doing more harm than good as it would just condition people to ignore these warnings altogether. As the poster mentioned, ubsan will catch the cases you actually care about, albeit at runtime. It's also worth noting that GCC does try to warn at compile time about a lot of the undefined behavior that you do care about, such as strict aliasing violations when -Wall is enabled.

0db532a0 8y ago
Could you explain why in this hypothetical scenario a warning should be emitted for “for (int i = 0...)”?
- inetknght 8y ago
  Range-based for loops are far more idiomatic for modern C++: https://stackoverflow.com/a/15089298/1111557 https://stackoverflow.com/a/15089298/1111557
  - saagarjha 8y ago
    They're also not in the standard library. Not everyone can justify integrating Boost into their applications :(
    - Y_Y 8y ago
      You can certainly do this with just the standard library and no boost, for example using iota from <numeric>. https://en.cppreference.com/w/cpp/algorithm/iota https://en.cppreference.com/w/cpp/algorithm/iota
      - saagarjha 8y ago
        That’s not a generator, though. You need to allocate an extra container for this to fill, which is inconvenient.
  - bonzini 8y ago
    And underneath they compile to an int for loop and a pointer dereference, both of which can be undefined behavior.
- platinumrad 8y ago
  bonzini's hypothetical scenario was one where the compiler emitted a warning every single time it encountered undefined behavior. Assuming that a loop counter cannot overflow because signed integer overflow is undefined is one such instance and would fall under the "99% false positives" that they mention.
  - jlebar 8y ago
    But of course this way leads to madness, because then we'd also have to warn every time you do `x + 1` or `*ptr`, both of which can lead to UB (if x is a signed integer and the addition overflows, or if ptr is null).
  - 0db532a0 8y ago
    Thanks.
inetknght 8y ago
> Would you want a warning to be emitted at compile time every single time you write "for (int i = 0...)"? Yes, I would. I have transitioned to always using ranged loops. I haven't had to write a "for (int i = 0...)" style loop for over a year. Even one where I thought it was still needed, I learned about zip iterator adapters from a C++ conference video; wrote my own, paired it with a proxy iterator, and the problem solved. Everywhere such a loop has existed, it has been replaced with generator class to provide the range needed. Not only would I want a warning, but I'd personally turn the warning into an error. I'm one of those dudes who runs around with pretty much as many warnings as possible turned on, and most of them turned into errors. Most of the warnings that are disabled by default are extremely helpful in preventing simple errors. Understanding what those warnings mean and how to resolve them is something I consider to be core understanding for anyone who wants to become more than a junior C++ developer. There's a _ton_ of libraries that don't work like that. Sucks to be them. Linking to boost works (most of the time) though, and that's the only real hard requirement I have.
- platinumrad 8y ago
  > I'm one of those dudes who runs around with pretty much as many warnings as possible turned on, and most of them turned into errors. Most of the warnings that are disabled by default are extremely helpful in preventing simple errors. Understanding what those warnings mean and how to resolve them is something I consider to be core understanding for anyone who wants to become more than a junior C++ developer. I strongly agree, which is why I think it's important that these warnings are not spurious. -Werror is no longer viable if what it takes to resolve warnings is more ceremony than substance. Emitting a warning every single time the compiler encounters undefined behavior would be utterly overwhelming given that the vast majority of these instances are harmless like skipping a load because it would be undefined behavior for a couple of pointers to alias. Obviously GCC and Clang could do more (for example, Clang doesn't implement -Wstrict-aliasing if I recall correctly), but their current approach of warning about UB when harmful, rather than reporting all UB, is correct in my opinion.
  - bollu 8y ago
    This is not going to save you either. To have this be efficient, the compiler needs to prove many things: for example, that the end iterator and the current iterator come from the same base object. Compilers don't do this, because comparing iterators from two different objects is UB.
cryptonector 8y ago
Yes, I do. It's easy to get into a habit of writing "for (size_t i = 0; ...)".

0db532a0 8y ago

Could you explain why in this hypothetical scenario a warning should be emitted for “for (int i = 0...)”?

inetknght 8y ago
Range-based for loops are far more idiomatic for modern C++: https://stackoverflow.com/a/15089298/1111557 https://stackoverflow.com/a/15089298/1111557
- saagarjha 8y ago
  They're also not in the standard library. Not everyone can justify integrating Boost into their applications :(
  - Y_Y 8y ago
    You can certainly do this with just the standard library and no boost, for example using iota from <numeric>. https://en.cppreference.com/w/cpp/algorithm/iota https://en.cppreference.com/w/cpp/algorithm/iota
    - saagarjha 8y ago
      That’s not a generator, though. You need to allocate an extra container for this to fill, which is inconvenient.
- bonzini 8y ago
  And underneath they compile to an int for loop and a pointer dereference, both of which can be undefined behavior.
platinumrad 8y ago
bonzini's hypothetical scenario was one where the compiler emitted a warning every single time it encountered undefined behavior. Assuming that a loop counter cannot overflow because signed integer overflow is undefined is one such instance and would fall under the "99% false positives" that they mention.
- jlebar 8y ago
  But of course this way leads to madness, because then we'd also have to warn every time you do `x + 1` or `*ptr`, both of which can lead to UB (if x is a signed integer and the addition overflows, or if ptr is null).
- 0db532a0 8y ago
  Thanks.

inetknght 8y ago

> Would you want a warning to be emitted at compile time every single time you write "for (int i = 0...)"? Yes, I would. I have transitioned to always using ranged loops. I haven't had to write a "for (int i = 0...)" style loop for over a year. Even one where I thought it was still needed, I learned about zip iterator adapters from a C++ conference video; wrote my own, paired it with a proxy iterator, and the problem solved. Everywhere such a loop has existed, it has been replaced with generator class to provide the range needed. Not only would I want a warning, but I'd personally turn the warning into an error. I'm one of those dudes who runs around with pretty much as many warnings as possible turned on, and most of them turned into errors. Most of the warnings that are disabled by default are extremely helpful in preventing simple errors. Understanding what those warnings mean and how to resolve them is something I consider to be core understanding for anyone who wants to become more than a junior C++ developer. There's a _ton_ of libraries that don't work like that. Sucks to be them. Linking to boost works (most of the time) though, and that's the only real hard requirement I have.

platinumrad 8y ago
> I'm one of those dudes who runs around with pretty much as many warnings as possible turned on, and most of them turned into errors. Most of the warnings that are disabled by default are extremely helpful in preventing simple errors. Understanding what those warnings mean and how to resolve them is something I consider to be core understanding for anyone who wants to become more than a junior C++ developer. I strongly agree, which is why I think it's important that these warnings are not spurious. -Werror is no longer viable if what it takes to resolve warnings is more ceremony than substance. Emitting a warning every single time the compiler encounters undefined behavior would be utterly overwhelming given that the vast majority of these instances are harmless like skipping a load because it would be undefined behavior for a couple of pointers to alias. Obviously GCC and Clang could do more (for example, Clang doesn't implement -Wstrict-aliasing if I recall correctly), but their current approach of warning about UB when harmful, rather than reporting all UB, is correct in my opinion.
- bollu 8y ago
  This is not going to save you either. To have this be efficient, the compiler needs to prove many things: for example, that the end iterator and the current iterator come from the same base object. Compilers don't do this, because comparing iterators from two different objects is UB.

cryptonector 8y ago

Yes, I do. It's easy to get into a habit of writing "for (size_t i = 0; ...)".