6 ms·

> However, there may still be a number of corner cases of the language like undefined behaviors. This is why people frequently fall into C's traps. I don't thi

> However, there may still be a number of corner cases of the language like undefined behaviors. This is why people frequently fall into C's traps. I don't think that's true; the UB that is relevant for day-to-day programming is easily learned. It's just that a sucker is born every minute and there's always someone who's been taught that C is a high level assembler. Now and then someone slips a piece of code that assumes as much in a project and disproportionately big noise is made about it. Most UB-related bugs in C code are not there because the author didn't know it's UB, but because they simply coded it wrong. People fall into simple buffer overflows, double frees, etcetra all the time and no-one thought it's ok to overflow a buffer.

jstimpfle 5y ago
Right. All this buzz about UB is a bit much. Sure, it's not great to have to assume that something breaks when you upgrade your compiler when the compiler authors made a change to exploit some UB that I didn't know of. On the other hand, I'm quite confident that I don't have much UB in my code (as running sanitizers from time to time confirms). And miraculously, I've never ever been surprised by "nasal daemons".
- MaxBarraclough 5y ago
  > All this buzz about UB is a bit much. No, the problem of undefined behaviour isn't overstated. It's the reason C and C++ have such a poor security track-record. > I'm quite confident that I don't have much UB in my code Plenty of C and C++ programmers are confident they don't have UB in their code, and yet we see a constant stream of security issues arising from UB in codebases developed and maintained by the smartest and most motivated C/C++ programmers, such as kernel code and the Chromium codebase. From the Chromium project: [0] > Around 70% of our high severity security bugs are memory unsafety problems (that is, mistakes with C/C++ pointers). Half of those are use-after-free bugs. These bugs are, of course, undefined behaviour. These are serious bugs that presumably made it through their code-review and code-analysis processes. (Chromium is written in C++ rather than C, but the point stands.) > running sanitizers from time to time confirms It doesn't. Modern static analysis tools are pretty smart, but they're a long way from being able to detect every instance of possible UB, with no false positives. If they were, we'd be in a very different place. With the current state-of-the-art, the only way we have of developing C/C++ codebases that are free of UB, is to use formal methods (e.g. SeL4). This approach is very rarely taken, on account of the impact on development speed, and the skill needed. [0] https://www.chromium.org/Home/chromium-security/memory-safety/ https://www.chromium.org/Home/chromium-security/memory-safet...
  - jstimpfle 5y ago
    I feel you've missed my point. I'm not saying that there are no exploitable or otherwise dangerous bugs. Of course there are, but the behaviour usually comes from obvious logic bugs and the consequences are pretty much as expected - e.g. memory gets corrupted as a consequence of an out-of-bounds write, and then almost anything could happen. And while this is "undefined behaviour", it is not what people mean when they complain about UB.
    - MaxBarraclough 5y ago
      > I'm not saying that there are no exploitable or otherwise dangerous bugs. Of course there are, but the behaviour usually comes from obvious logic bugs Difficult-to-detect undefined behaviour is a significant problem with C and C++, otherwise it wouldn't be a major cause of serious security vulnerabilities in well-resourced, high-profile, security-sensitive C/C++ codebases. There may also be many instances of easily-detected undefined behaviour that exist only because of sloppy software development. There may also be many instances of undefined behaviour that are relatively benign. > and the consequences are pretty much as expected - e.g. memory gets corrupted as a consequence of an out-of-bounds write, and then almost anything could happen. I don't think I'm seeing your point. We agree that undefined behaviour can have serious consequences. > while this is "undefined behaviour", it is not what people mean when they complain about UB I don't follow. Undefined behaviour is an unambiguous term of art in C and C++ programming. There are plenty of common misconceptions about UB, sure enough, but the term itself is precise.
      - jstimpfle 5y ago
        > Difficult-to-detect undefined behaviour is a significant problem with C and C++, otherwise it wouldn't be a major cause of serious security vulnerabilities in well-resourced, high-profile, security-sensitive C/C++ codebases. Do you mean difficult-to-detect but "obviously" bugs that can lead to UB, like buffer overflows that only happen in rare circumstances (like with unsanitized input)? Or do you mean difficult to detect unexpected "miscompilations" by the compiler based on some UB that is non-obvious to most programmers and/or not well-known? Because I was referring to the latter, and in my perception most talk about UB is. I haven't seen the latter happen myself, and I haven't read that many horror stories where this actually happened. For better or worse, I'm not angry with the compiler if I code a logic bug and corruption happens. That's just what I expect. Maybe if you're indeed saying the latter is a "major cause of security vulnerabilities", could you provide a few examples where it's the language's or compiler's "fault"? I can see that the line is not well defined here of course, because technically it's all just UB - but the distinction really was my point, which I made from a practical perspective.

jstimpfle 5y ago

Right. All this buzz about UB is a bit much. Sure, it's not great to have to assume that something breaks when you upgrade your compiler when the compiler authors made a change to exploit some UB that I didn't know of. On the other hand, I'm quite confident that I don't have much UB in my code (as running sanitizers from time to time confirms). And miraculously, I've never ever been surprised by "nasal daemons".

MaxBarraclough 5y ago
> All this buzz about UB is a bit much. No, the problem of undefined behaviour isn't overstated. It's the reason C and C++ have such a poor security track-record. > I'm quite confident that I don't have much UB in my code Plenty of C and C++ programmers are confident they don't have UB in their code, and yet we see a constant stream of security issues arising from UB in codebases developed and maintained by the smartest and most motivated C/C++ programmers, such as kernel code and the Chromium codebase. From the Chromium project: [0] > Around 70% of our high severity security bugs are memory unsafety problems (that is, mistakes with C/C++ pointers). Half of those are use-after-free bugs. These bugs are, of course, undefined behaviour. These are serious bugs that presumably made it through their code-review and code-analysis processes. (Chromium is written in C++ rather than C, but the point stands.) > running sanitizers from time to time confirms It doesn't. Modern static analysis tools are pretty smart, but they're a long way from being able to detect every instance of possible UB, with no false positives. If they were, we'd be in a very different place. With the current state-of-the-art, the only way we have of developing C/C++ codebases that are free of UB, is to use formal methods (e.g. SeL4). This approach is very rarely taken, on account of the impact on development speed, and the skill needed. [0] https://www.chromium.org/Home/chromium-security/memory-safety/ https://www.chromium.org/Home/chromium-security/memory-safet...
- jstimpfle 5y ago
  I feel you've missed my point. I'm not saying that there are no exploitable or otherwise dangerous bugs. Of course there are, but the behaviour usually comes from obvious logic bugs and the consequences are pretty much as expected - e.g. memory gets corrupted as a consequence of an out-of-bounds write, and then almost anything could happen. And while this is "undefined behaviour", it is not what people mean when they complain about UB.
  - MaxBarraclough 5y ago
    > I'm not saying that there are no exploitable or otherwise dangerous bugs. Of course there are, but the behaviour usually comes from obvious logic bugs Difficult-to-detect undefined behaviour is a significant problem with C and C++, otherwise it wouldn't be a major cause of serious security vulnerabilities in well-resourced, high-profile, security-sensitive C/C++ codebases. There may also be many instances of easily-detected undefined behaviour that exist only because of sloppy software development. There may also be many instances of undefined behaviour that are relatively benign. > and the consequences are pretty much as expected - e.g. memory gets corrupted as a consequence of an out-of-bounds write, and then almost anything could happen. I don't think I'm seeing your point. We agree that undefined behaviour can have serious consequences. > while this is "undefined behaviour", it is not what people mean when they complain about UB I don't follow. Undefined behaviour is an unambiguous term of art in C and C++ programming. There are plenty of common misconceptions about UB, sure enough, but the term itself is precise.
    - jstimpfle 5y ago
      > Difficult-to-detect undefined behaviour is a significant problem with C and C++, otherwise it wouldn't be a major cause of serious security vulnerabilities in well-resourced, high-profile, security-sensitive C/C++ codebases. Do you mean difficult-to-detect but "obviously" bugs that can lead to UB, like buffer overflows that only happen in rare circumstances (like with unsanitized input)? Or do you mean difficult to detect unexpected "miscompilations" by the compiler based on some UB that is non-obvious to most programmers and/or not well-known? Because I was referring to the latter, and in my perception most talk about UB is. I haven't seen the latter happen myself, and I haven't read that many horror stories where this actually happened. For better or worse, I'm not angry with the compiler if I code a logic bug and corruption happens. That's just what I expect. Maybe if you're indeed saying the latter is a "major cause of security vulnerabilities", could you provide a few examples where it's the language's or compiler's "fault"? I can see that the line is not well defined here of course, because technically it's all just UB - but the distinction really was my point, which I made from a practical perspective.