5 ms·

The first rule of C good programming "Treat warnings as errors". Compile with all warnings enabled, selectively ignore only warnings you know for sure are not

The first rule of C good programming "Treat warnings as errors". Compile with all warnings enabled, selectively ignore only warnings you know for sure are not important for program semantics. Simple MISRA C with all warnings on is already close to language with strict type checking. C compilers give you a choice, use it. If you are programming for money, good static analyzer makes it possible to write safety critical code.

veltas 4y ago
I do agree about compiler warnings, but MISRA C imposes a lot of unnecessary rules, a lot of unhelpful rules on how you write expressions, and tries to also act like C's type system works a different way than it does. In practice I have found it to actually create bugs. Read the MISRA rules and appendices on their effective type model and the C standard, they have gaps where MISRA actually forces you to write code that looks correct and doesn't work with C's model. I strongly recommend against using MISRA, even in automotive or aviation code (although it may unfortunately be a requirement on any such project).
pjmlp 4y ago
Worth noting Dennis own words, "Although the first edition of K&R described most of the rules that brought C's type structure to its present form, many programs written in the older, more relaxed style persisted, and so did compilers that tolerated it. To encourage people to pay more attention to the official language rules, to detect legal but suspicious constructions, and to help find interface mismatches undetectable with simple mechanisms for separate compilation, Steve Johnson adapted his pcc compiler to produce lint [Johnson 79b], which scanned a set of files and remarked on dubious constructions." Dennis M. Ritchie -- https://www.bell-labs.com/usr/dmr/www/chist.html https://www.bell-labs.com/usr/dmr/www/chist.html Unfortunately too many think they know better than the language authors themselves.
- protomikron 4y ago
  What is the history of "undefined behavior" [in C compilers and the standard] in general? I suppose originally it was supposed to guide compiler engineers, but we all know that backfired, as many compilers try to exploit undefined behavior to optimize code, but that can be problematic in security sensitive code (e.g. if uninitialized memory is optimized away) - there have been discussions between security engineers, kernel developers and GCC hackers about how to implement/interpret the standard. Would it be possible to have a standard, where undefined behavior is just a compile error? What would we lose - apart from legacy compatibility?
  - Veliladon 4y ago
    That's pretty much what Rust was created to do.
    - pjmlp 4y ago
      Like many others before it, hopefully it gets more adoption this time.
  - jcranmer 4y ago
    > Would it be possible to have a standard, where undefined behavior is just a compile error? No [if you're aiming for something in the same vein as C]. Undefined behavior is ultimately an inherently dynamic property--certain values could make a statement execute undefined behavior, and consequently, virtually every statement could potentially cause undefined behavior. Note that this remains true even in languages like Rust: Rust has loads of undefined behavior, but you do have to wrap code in unsafe blocks to potentially cause undefined behavior. > What would we lose - apart from legacy compatibility? In particular, it is clear at this point that if you want to permit converting integers to pointers, you will either have to live with undefined behavior (via pointer provenance) or forgo basically all optimization whatsoever.
  - pjmlp 4y ago
    C sucked on 8 and 16 bit home computers, to be fair, all high level systems programming languages had their own set of issues regarding optimal code generation, thus Assembly was the name of the name for ultimate performance. UB started as means to not kick out computer architectures that would otherwise not be able to be targeted by fully compliant ISO C compilers. Given that C prefers to be a kind of portable macro assembler than care about security, it was only a matter of time until those escape hatches started to be taken advantage for optimizations. Same applies to other languages, however since their communities tend to prefer security before ultimate performance, some optimization paths are not considered as that would hurt their safety goals. In what concerns C, C++ and Objective-C, dropping UB optimizations would mean going back to the 1990's in terms of code quality.
  - robryk 4y ago
wyldfire 4y ago
Unfortunately some of this stuff just can't be detected statically. So while warnings are an excellent starting point, I recommend also building and testing with UBSan+ASan enabled.

veltas 4y ago

I do agree about compiler warnings, but MISRA C imposes a lot of unnecessary rules, a lot of unhelpful rules on how you write expressions, and tries to also act like C's type system works a different way than it does. In practice I have found it to actually create bugs. Read the MISRA rules and appendices on their effective type model and the C standard, they have gaps where MISRA actually forces you to write code that looks correct and doesn't work with C's model. I strongly recommend against using MISRA, even in automotive or aviation code (although it may unfortunately be a requirement on any such project).

pjmlp 4y ago

Worth noting Dennis own words, "Although the first edition of K&R described most of the rules that brought C's type structure to its present form, many programs written in the older, more relaxed style persisted, and so did compilers that tolerated it. To encourage people to pay more attention to the official language rules, to detect legal but suspicious constructions, and to help find interface mismatches undetectable with simple mechanisms for separate compilation, Steve Johnson adapted his pcc compiler to produce lint [Johnson 79b], which scanned a set of files and remarked on dubious constructions." Dennis M. Ritchie -- https://www.bell-labs.com/usr/dmr/www/chist.html https://www.bell-labs.com/usr/dmr/www/chist.html Unfortunately too many think they know better than the language authors themselves.

protomikron 4y ago
What is the history of "undefined behavior" [in C compilers and the standard] in general? I suppose originally it was supposed to guide compiler engineers, but we all know that backfired, as many compilers try to exploit undefined behavior to optimize code, but that can be problematic in security sensitive code (e.g. if uninitialized memory is optimized away) - there have been discussions between security engineers, kernel developers and GCC hackers about how to implement/interpret the standard. Would it be possible to have a standard, where undefined behavior is just a compile error? What would we lose - apart from legacy compatibility?
- Veliladon 4y ago
  That's pretty much what Rust was created to do.
  - pjmlp 4y ago
    Like many others before it, hopefully it gets more adoption this time.
- jcranmer 4y ago
  > Would it be possible to have a standard, where undefined behavior is just a compile error? No [if you're aiming for something in the same vein as C]. Undefined behavior is ultimately an inherently dynamic property--certain values could make a statement execute undefined behavior, and consequently, virtually every statement could potentially cause undefined behavior. Note that this remains true even in languages like Rust: Rust has loads of undefined behavior, but you do have to wrap code in unsafe blocks to potentially cause undefined behavior. > What would we lose - apart from legacy compatibility? In particular, it is clear at this point that if you want to permit converting integers to pointers, you will either have to live with undefined behavior (via pointer provenance) or forgo basically all optimization whatsoever.
- pjmlp 4y ago
  C sucked on 8 and 16 bit home computers, to be fair, all high level systems programming languages had their own set of issues regarding optimal code generation, thus Assembly was the name of the name for ultimate performance. UB started as means to not kick out computer architectures that would otherwise not be able to be targeted by fully compliant ISO C compilers. Given that C prefers to be a kind of portable macro assembler than care about security, it was only a matter of time until those escape hatches started to be taken advantage for optimizations. Same applies to other languages, however since their communities tend to prefer security before ultimate performance, some optimization paths are not considered as that would hurt their safety goals. In what concerns C, C++ and Objective-C, dropping UB optimizations would mean going back to the 1990's in terms of code quality.
- robryk 4y ago

wyldfire 4y ago

Unfortunately some of this stuff just can't be detected statically. So while warnings are an excellent starting point, I recommend also building and testing with UBSan+ASan enabled.