4 ms·

It's quite ironic that on a page about safety they use an if statement without {} braces: if(x % 2) vec^.push_back(x); unsafe printf

It's quite ironic that on a page about safety they use an if statement without {} braces: if(x % 2) vec^.push_back(x); unsafe printf("%d\n", x); Skipping the braces for single line conditionals in C++ is a lazy practice that almost inevitably leads to bugs, like Apple's famous goto fail bug: https://www.synopsys.com/blogs/software-security/understanding-apple-goto-fail-vulnerability-2.html https://www.synopsys.com/blogs/software-security/understandi... . While memory bugs are difficult to prevent, this particular class of logic bug can be eliminated entirely just by always remembering to write two {} around the statement, so a language concerned with correctness should promote such good practices. if(x % 2){ vec^.push_back(x); }

jandrewrogers 2y ago
This is nitpicking style, there are no real safety implications. Compilers will happily inform you if the parse is ambiguous or code is unreachable.
- logicchains 2y ago
  If you write in this style then there's the possibility that someone else (or yourself in future) will add a second line, like: if(x % 2) vec^.push_back(x); do_something_else(); under the mistaken assumption that the second line will also only run in the x % 2 case. People make mistakes, this particular one can happen, does happen, and has happened many times, and the compiler absolutely will not inform or warn you, because it doesn't know you intended the second line to run in the same if statement as the first (because C++ isn't whitespace sensitive). Is ruling out an entire class of bug really not worth the effort of just typing two more characters?
  - j16sdiz 2y ago
    Indentation can be fixed with a code formatter in pre commit hook.
    - dragonwriter 2y ago
      Or even an on-save or (and more likely to prevent this kind of error in a large file) as-you-type feature in your IDE/editor.
      - dllthomas 2y ago
        Available autoformatting is great, but IIRC the Apple issue happened in an automatic merge. Autoformatting would still help it be noticed, when someone wondered why the formatter changed some bit of the code they hadn't touched, but a formatting check in with the automated tests would catch it faster.
  - throwaway376512 2y ago
    > and the compiler absolutely will not inform or warn you False. https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wmisleading-indentation https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#inde... https://clang.llvm.org/docs/DiagnosticsReference.html#wmisleading-indentation https://clang.llvm.org/docs/DiagnosticsReference.html#wmisle...
Gibbon1 2y ago
That feels like a I was learning how to program and this bit me and now I'm always scared of it type of bug. I've never seen it myself. But then again some of my friends complain about OCD coworkers that can't not obsessively remove blank lines from code. I have seen for(size_t i=0; i<n; i++); foo(i); if(a>b); a=b; The famous goto bug was because the assholes had no tests for that module.

jandrewrogers 2y ago

This is nitpicking style, there are no real safety implications. Compilers will happily inform you if the parse is ambiguous or code is unreachable.

logicchains 2y ago
If you write in this style then there's the possibility that someone else (or yourself in future) will add a second line, like: if(x % 2) vec^.push_back(x); do_something_else(); under the mistaken assumption that the second line will also only run in the x % 2 case. People make mistakes, this particular one can happen, does happen, and has happened many times, and the compiler absolutely will not inform or warn you, because it doesn't know you intended the second line to run in the same if statement as the first (because C++ isn't whitespace sensitive). Is ruling out an entire class of bug really not worth the effort of just typing two more characters?
- j16sdiz 2y ago
  Indentation can be fixed with a code formatter in pre commit hook.
  - dragonwriter 2y ago
    Or even an on-save or (and more likely to prevent this kind of error in a large file) as-you-type feature in your IDE/editor.
    - dllthomas 2y ago
      Available autoformatting is great, but IIRC the Apple issue happened in an automatic merge. Autoformatting would still help it be noticed, when someone wondered why the formatter changed some bit of the code they hadn't touched, but a formatting check in with the automated tests would catch it faster.
- throwaway376512 2y ago
  > and the compiler absolutely will not inform or warn you False. https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wmisleading-indentation https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#inde... https://clang.llvm.org/docs/DiagnosticsReference.html#wmisleading-indentation https://clang.llvm.org/docs/DiagnosticsReference.html#wmisle...

Gibbon1 2y ago

That feels like a I was learning how to program and this bit me and now I'm always scared of it type of bug. I've never seen it myself. But then again some of my friends complain about OCD coworkers that can't not obsessively remove blank lines from code. I have seen for(size_t i=0; i<n; i++); foo(i); if(a>b); a=b; The famous goto bug was because the assholes had no tests for that module.