5 ms·

> There are many ways of writing wrong C code, but you only need to make sure what you write is correct and in defined behavior, that’s all about C programming.

by gilmi 7y ago

> There are many ways of writing wrong C code, but you only need to make sure what you write is correct and in defined behavior, that’s all about C programming. But this is a something that even experts fail to do.

butteroverflow 7y ago
Yeah, you "only" need to avoid undefined behavior. What do we need ASAN/UBSAN for then? https://github.com/google/sanitizers/ https://github.com/google/sanitizers/ Sure, Google is primarily a C++ shop, you could say that C++ is to blame and it has nothing to do with C. But why the need for KASAN then? Which has a big track record at this point, by the way.
- orbifold 7y ago
  There are developers at google (most likely in increasing numbers) that would look like a deer caught in the headlights when asked to work on a C++ part of the code base (anecdotally according to a guy working at Google)
bsder 7y ago
Yeah, I have yet to meet someone who claims to write correct C code. Mozilla decided that it was such a difficult task in C/C++ that they created their own language.
- kazinator 7y ago
  Twenty years ago I wrote C++ code that was easily verifiable to be memory safe and free of leaks, just by using a handful of smart classes and sticking to them.
  - lifthrasiir 7y ago
    But did you verify it never overflows? I think it is much harder to get that right without language (or compiler) support. Keep it mind that overflow is as severe as memory bug in C/C++ due to the unforgiving nature of UBs in those languages.
    - kazinator 7y ago
      Had integers wrapped in a class, yes. > that overflow is as severe as memory bug in C/C++ In practice, it isn't. In many traditional compilers it has predictable behavior (two's complement wrapping), if we're not talking about floating-point overflow. Some programs explicitly rely on it. Compiler support can be provided for those programs. It's simply not in the same category as memory corruption bugs. Of course, ISO C and C++ have just one category for undefined! However, note that "undefined behavior" is a formal term which extends over beneficial areas such as documented extensions and the use of third-party libraries and headers.
      - bsder 7y ago
        > Had integers wrapped in a class, yes. Okay, you were serious about safety. Congratulations, you are the first one I have ever come across. I have never seen anyone else wrap integers in a class in order to use them with stable semantics.
        kazinator 7y ago
        That was practically a poster example to sell C++. Look, you can overload operators and get arrays with bounds checking, integers that trap overflows and so on. Twenty years ago, C++ was still hot and there was a lot of interest in all sorts of techniques. Books, seminars, papers, blogs, you name it. There is a way to use C++ template partial specialization to mimic the built-in conversion rules, like "int op long" promoting the left operan to "int". You can mirror the language in itself and bend the rules.
  - roca 7y ago
    "Using a handful of smart classes and sticking to them" by no means guarantees memory safety, unless you also rule out references and a bunch of other normal C++ features.
    - kazinator 7y ago
      I made use of const references in the code to avoid some unnecessary refcount bumping. I hadn't ruled out calling outside platform API functions, which were all written in C. You can't do that in any language, unless you're writing a pure text filter or calculator for the Unix command line environment (and don't count the I/O and math functions).
  - pjmlp 7y ago
    Twenty years ago I was also mostly a C++ dev and unless the code was 100% written by me I would never issue such statement, given the total lack of control what others in the team or binary 3rd party libraries are doing. I still use C++ as one of my favourite hobby languages and althought it has improved a lot, using C++20 best practice across a team (lets assume it is already available), with binary dependencies, is still a challange to make it 100% memory safe.
    - kazinator 7y ago
      > unless the code was 100% written by me I would never issue such statement It was 100% written by me. Note that the Rust devs made an entire 100% written-by-them-language to make the same claims.
      - pjmlp 7y ago
        It is a bit different though. In C++ static analysis is optional, while it is part of language in Rust. Then there is the whole language culture. While me coming from stronger system languages, always strived for bounds checking enabled on my own C++ projects, good luck selling that to most C++ teams, even though in 99% of the use cases its impact is negligible. Finally going all the way back to NEWP, system languages that require explicit unsafe blocks are much easier to do code review, than those where every line of code can possibly trigger unsafe behaviour, and C++ inherited lot of such cases from C.
        deleted 7y ago
        [deleted]
kazinator 7y ago
It is something experts must fail to do. Documented extensions fall under "undefined behavior", and a lot of real-world coding requires them. Oh, and use of header files and functions not in ISO C is undefined behavior. On a POSIX system #include <fcntl.h> provides definitions of things like F_DUPFD. But there is no reason why on some non-POSIX system, #include <fcntl.h> might not cause the rest of the translation unit to be compiled as Fortran 77. The include mechanism per se has the well-defined behavior that, if the header is found, it replaces itself by the content, which is thereby incorporated into the translation unit. But if that header isn't coming from the program, or from ISO C, then the content is not defined by ISO C.
hburd 7y ago
Is undefined behavior really that bad when it's not causing problems?
- merijnv 7y ago
  The problem is that, just because it's not causing problems now, doesn't mean it can suddenly start causing incredibly hard to track down problems years later after an innocuous compiler upgrade...
- kazinator 7y ago
  "Undefined behavior" is a broad area which covers everything from defects in a program that make it crash, to documented language and library extensions (which real-world programs can hardly avoid using).
sureaboutthis 7y ago
Well I'm glad that other languages prevent experts from writing wrong code.

by gilmi 7y ago

butteroverflow 7y ago

Yeah, you "only" need to avoid undefined behavior. What do we need ASAN/UBSAN for then? https://github.com/google/sanitizers/ https://github.com/google/sanitizers/ Sure, Google is primarily a C++ shop, you could say that C++ is to blame and it has nothing to do with C. But why the need for KASAN then? Which has a big track record at this point, by the way.

orbifold 7y ago
There are developers at google (most likely in increasing numbers) that would look like a deer caught in the headlights when asked to work on a C++ part of the code base (anecdotally according to a guy working at Google)

bsder 7y ago

Yeah, I have yet to meet someone who claims to write correct C code. Mozilla decided that it was such a difficult task in C/C++ that they created their own language.

kazinator 7y ago
Twenty years ago I wrote C++ code that was easily verifiable to be memory safe and free of leaks, just by using a handful of smart classes and sticking to them.
- lifthrasiir 7y ago
  But did you verify it never overflows? I think it is much harder to get that right without language (or compiler) support. Keep it mind that overflow is as severe as memory bug in C/C++ due to the unforgiving nature of UBs in those languages.
  - kazinator 7y ago
    Had integers wrapped in a class, yes. > that overflow is as severe as memory bug in C/C++ In practice, it isn't. In many traditional compilers it has predictable behavior (two's complement wrapping), if we're not talking about floating-point overflow. Some programs explicitly rely on it. Compiler support can be provided for those programs. It's simply not in the same category as memory corruption bugs. Of course, ISO C and C++ have just one category for undefined! However, note that "undefined behavior" is a formal term which extends over beneficial areas such as documented extensions and the use of third-party libraries and headers.
    - bsder 7y ago
      > Had integers wrapped in a class, yes. Okay, you were serious about safety. Congratulations, you are the first one I have ever come across. I have never seen anyone else wrap integers in a class in order to use them with stable semantics.
      - kazinator 7y ago
        That was practically a poster example to sell C++. Look, you can overload operators and get arrays with bounds checking, integers that trap overflows and so on. Twenty years ago, C++ was still hot and there was a lot of interest in all sorts of techniques. Books, seminars, papers, blogs, you name it. There is a way to use C++ template partial specialization to mimic the built-in conversion rules, like "int op long" promoting the left operan to "int". You can mirror the language in itself and bend the rules.
- roca 7y ago
  "Using a handful of smart classes and sticking to them" by no means guarantees memory safety, unless you also rule out references and a bunch of other normal C++ features.
  - kazinator 7y ago
    I made use of const references in the code to avoid some unnecessary refcount bumping. I hadn't ruled out calling outside platform API functions, which were all written in C. You can't do that in any language, unless you're writing a pure text filter or calculator for the Unix command line environment (and don't count the I/O and math functions).
- pjmlp 7y ago
  Twenty years ago I was also mostly a C++ dev and unless the code was 100% written by me I would never issue such statement, given the total lack of control what others in the team or binary 3rd party libraries are doing. I still use C++ as one of my favourite hobby languages and althought it has improved a lot, using C++20 best practice across a team (lets assume it is already available), with binary dependencies, is still a challange to make it 100% memory safe.
  - kazinator 7y ago
    > unless the code was 100% written by me I would never issue such statement It was 100% written by me. Note that the Rust devs made an entire 100% written-by-them-language to make the same claims.
    - pjmlp 7y ago
      It is a bit different though. In C++ static analysis is optional, while it is part of language in Rust. Then there is the whole language culture. While me coming from stronger system languages, always strived for bounds checking enabled on my own C++ projects, good luck selling that to most C++ teams, even though in 99% of the use cases its impact is negligible. Finally going all the way back to NEWP, system languages that require explicit unsafe blocks are much easier to do code review, than those where every line of code can possibly trigger unsafe behaviour, and C++ inherited lot of such cases from C.
      - deleted 7y ago
        [deleted]

kazinator 7y ago

It is something experts must fail to do. Documented extensions fall under "undefined behavior", and a lot of real-world coding requires them. Oh, and use of header files and functions not in ISO C is undefined behavior. On a POSIX system #include <fcntl.h> provides definitions of things like F_DUPFD. But there is no reason why on some non-POSIX system, #include <fcntl.h> might not cause the rest of the translation unit to be compiled as Fortran 77. The include mechanism per se has the well-defined behavior that, if the header is found, it replaces itself by the content, which is thereby incorporated into the translation unit. But if that header isn't coming from the program, or from ISO C, then the content is not defined by ISO C.

hburd 7y ago

Is undefined behavior really that bad when it's not causing problems?

merijnv 7y ago
The problem is that, just because it's not causing problems now, doesn't mean it can suddenly start causing incredibly hard to track down problems years later after an innocuous compiler upgrade...
kazinator 7y ago
"Undefined behavior" is a broad area which covers everything from defects in a program that make it crash, to documented language and library extensions (which real-world programs can hardly avoid using).

sureaboutthis 7y ago

Well I'm glad that other languages prevent experts from writing wrong code.