3 ms·

If it were so easy, there would be already specified a subset of C without undefined behavior and you could be able to automatically check your code against it.

by rini17 6y ago

gonzo41 6y ago
You could follow NASA standards. They've got a pretty good record with c. But it'll cost you.
- MaxBarraclough 6y ago
  Link: https://web.archive.org/web/20190213011655/http://homepages.inf.ed.ac.uk/dts/pm/Papers/nasa-c-style.pdf https://web.archive.org/web/20190213011655/http://homepages.... Alternatively, NASA host an uglier scan of the document at https://ntrs.nasa.gov/citations/19950022400 https://ntrs.nasa.gov/citations/19950022400
MaxBarraclough 6y ago
My point was only that C programmers should be keenly aware of the pitfalls of undefined behaviour, rather than blithely ignoring it. I've been surprised by the sloppiness of some developers on this point. > a subset of C without undefined behavior There are various projects out there that let you produce C code guaranteed to be free of undefined behaviour, but they're not 'quick fix' solutions, so they're not widely used. https://www.eschertech.com/products/ https://www.eschertech.com/products/ https://github.com/zetzit/zz https://github.com/zetzit/zz https://blog.regehr.org/archives/1069 https://blog.regehr.org/archives/1069 (ctrl-f for actually)
- rini17 6y ago
  What does "keenly aware" even mean? For example: any time I add or subtract two signed ints, undefined behavior can happen. Now what. Must I pepper the code with bounds checks (which are prone to UB too if not done carefully)? Anyway, any complicated thing that can be easily ignored, inevitably will be.
  - MaxBarraclough 6y ago
    > What does "keenly aware" even mean? Keeping the threat of undefined behaviour in mind, and taking steps accordingly, rather than complacently ignoring it. C is a highly unsafe language, and the programmer shouldn't forget this. > any complicated thing that can be easily ignored, inevitably will be. The demonstrable inability of C programmers to write correct code is a strong argument against the widespread use of C. Even old languages like Ada show that you can use a language much safer than C and still achieve solid performance. Languages like Rust are making further progress on having safety, performance, and programmer-convenience, all at once. If you use an ultra-safe language like verified SPARK Ada, the language doesn't even allow you to, say, forget to check whether a denominator is zero, or to forget to protect against out-of-bounds array access. > Must I pepper the code with bounds checks (which are prone to UB too if not done carefully)? Not necessarily; a tool can help check for undefined behaviour. Static analysers, GCC flags, and tools like Valgrind, can automatically check for out-of-bounds array access, divide-by-zero, or attempting to dereference NULL. [0] Adding your own runtime assertions isn't a crazy idea though, especially for dev builds. If this were the norm in C programming we'd have fewer security vulnerabilities. C lacks the kind of runtime checks that are 'always on' in languages like Java and C# (out-of-bounds, divide-by-zero, etc). That's not because such checks don't apply to C code, it's because of the minimalist C design philosophy. You have the option to add your own checks, or use tools to do so automatically, but if you develop without any checks anywhere you should expect to have more bugs. Java added them for a reason. The C++ language has a somewhat different design philosophy, but it's the same reason its std::array class-template has both a runtime-checked at member-function, and an unchecked operator[]. It would be against the design philosophy to force you to pay the runtime overhead for checks, but it gives you the option. > which are prone to UB too if not done carefully What kind of error do you have in mind here? [0] https://stackoverflow.com/a/44820924/ https://stackoverflow.com/a/44820924/
    - rini17 6y ago
      For example checking for signed overflow must be done carefully: https://stackoverflow.com/questions/3944505/detecting-signed-overflow-in-c-c https://stackoverflow.com/questions/3944505/detecting-signed... "Design philosophy"...oh please! C was designed for transistor- and memory- scarce microcomputers. Nowadays there is defacto supercomputer in every phone and runtime bounds checks are cheap. Moreover, allowing CPU to know the size of memory chunk pointed to could enable optimization which would make the code actually faster (not even talking about security benefits). But you C programmers insist tooth an nail against that...
- chaz72 6y ago
  I've been actively wondering about generating some efficient and portable C code, and for this project it wouldn't be super-complicated, but undefined behavior is the one thing that keeps me away. C++ and Rust and C# and many other languages all add wonderful things, with side effects on portability, clarity, learning curve, language stability, etc. - wonderful things that I don't always want in a twenty-year-stable system. Anyway, thank you for these, I'm definitely going to look further here.

If it were so easy, there would be already specified a subset of C without undefined behavior and you could be able to automatically check your code against it.

by rini17 6y ago

If it were so easy, there would be already specified a subset of C without undefined behavior and you could be able to automatically check your code against it.

gonzo41 6y ago

You could follow NASA standards. They've got a pretty good record with c. But it'll cost you.

MaxBarraclough 6y ago
Link: https://web.archive.org/web/20190213011655/http://homepages.inf.ed.ac.uk/dts/pm/Papers/nasa-c-style.pdf https://web.archive.org/web/20190213011655/http://homepages.... Alternatively, NASA host an uglier scan of the document at https://ntrs.nasa.gov/citations/19950022400 https://ntrs.nasa.gov/citations/19950022400

MaxBarraclough 6y ago

My point was only that C programmers should be keenly aware of the pitfalls of undefined behaviour, rather than blithely ignoring it. I've been surprised by the sloppiness of some developers on this point. > a subset of C without undefined behavior There are various projects out there that let you produce C code guaranteed to be free of undefined behaviour, but they're not 'quick fix' solutions, so they're not widely used. https://www.eschertech.com/products/ https://www.eschertech.com/products/ https://github.com/zetzit/zz https://github.com/zetzit/zz https://blog.regehr.org/archives/1069 https://blog.regehr.org/archives/1069 (ctrl-f for actually)

rini17 6y ago
What does "keenly aware" even mean? For example: any time I add or subtract two signed ints, undefined behavior can happen. Now what. Must I pepper the code with bounds checks (which are prone to UB too if not done carefully)? Anyway, any complicated thing that can be easily ignored, inevitably will be.
- MaxBarraclough 6y ago
  > What does "keenly aware" even mean? Keeping the threat of undefined behaviour in mind, and taking steps accordingly, rather than complacently ignoring it. C is a highly unsafe language, and the programmer shouldn't forget this. > any complicated thing that can be easily ignored, inevitably will be. The demonstrable inability of C programmers to write correct code is a strong argument against the widespread use of C. Even old languages like Ada show that you can use a language much safer than C and still achieve solid performance. Languages like Rust are making further progress on having safety, performance, and programmer-convenience, all at once. If you use an ultra-safe language like verified SPARK Ada, the language doesn't even allow you to, say, forget to check whether a denominator is zero, or to forget to protect against out-of-bounds array access. > Must I pepper the code with bounds checks (which are prone to UB too if not done carefully)? Not necessarily; a tool can help check for undefined behaviour. Static analysers, GCC flags, and tools like Valgrind, can automatically check for out-of-bounds array access, divide-by-zero, or attempting to dereference NULL. [0] Adding your own runtime assertions isn't a crazy idea though, especially for dev builds. If this were the norm in C programming we'd have fewer security vulnerabilities. C lacks the kind of runtime checks that are 'always on' in languages like Java and C# (out-of-bounds, divide-by-zero, etc). That's not because such checks don't apply to C code, it's because of the minimalist C design philosophy. You have the option to add your own checks, or use tools to do so automatically, but if you develop without any checks anywhere you should expect to have more bugs. Java added them for a reason. The C++ language has a somewhat different design philosophy, but it's the same reason its std::array class-template has both a runtime-checked at member-function, and an unchecked operator[]. It would be against the design philosophy to force you to pay the runtime overhead for checks, but it gives you the option. > which are prone to UB too if not done carefully What kind of error do you have in mind here? [0] https://stackoverflow.com/a/44820924/ https://stackoverflow.com/a/44820924/
  - rini17 6y ago
    For example checking for signed overflow must be done carefully: https://stackoverflow.com/questions/3944505/detecting-signed-overflow-in-c-c https://stackoverflow.com/questions/3944505/detecting-signed... "Design philosophy"...oh please! C was designed for transistor- and memory- scarce microcomputers. Nowadays there is defacto supercomputer in every phone and runtime bounds checks are cheap. Moreover, allowing CPU to know the size of memory chunk pointed to could enable optimization which would make the code actually faster (not even talking about security benefits). But you C programmers insist tooth an nail against that...
chaz72 6y ago
I've been actively wondering about generating some efficient and portable C code, and for this project it wouldn't be super-complicated, but undefined behavior is the one thing that keeps me away. C++ and Rust and C# and many other languages all add wonderful things, with side effects on portability, clarity, learning curve, language stability, etc. - wonderful things that I don't always want in a twenty-year-stable system. Anyway, thank you for these, I'm definitely going to look further here.