3 ms·

Suppose Debian decides to hire you as their new release maintainer. They want to ensure that bugs such as the OpenSSL one mentioned in the article never happen

Suppose Debian decides to hire you as their new release maintainer. They want to ensure that bugs such as the OpenSSL one mentioned in the article never happen again. What actions would you take before next month's release to attempt to catch it? I see from your comment that you might hire a team of developers to go through a critical path of important C/C++ packages checking for style violations. Any code found missing braces will have a patch submitted upstream to correct the errant style. Any package that declines the style changes would be removed from Debian. Any developer you hire that misses style violations will be removed from the team. Another approach might be: Turn on the warning mentioned in the article and manually review any cases that come up. That still might generate a lot of cases, but it at least seems possible. Is there another actionable interpretation of your comment that I'm missing?

gravypod 11y ago
No. That is not what I mean. If you look at my response to iainmerric you will see that I don't feel you should change code that is working. This type of bug is largely introduced from someone who is going in and changing a section of code. My philosophy is that if you are editing a section of code, you should update the braces in that section along with your current patch. Over time you see a larger and larger drop in these kinds of bugs as people always, on my team due to the habit of fixing braces and a matching drop from outside contributes due to a larger and larger portion of the code matching the style guide.
- mikeash 11y ago
  That seems like a somewhat different case, though. Your approach will help prevent new bugs like this from being introduced, but won't help you against existing examples of it in areas you're not currently working on. And just because it's been around a long time doesn't mean it's "working." Goto fail showed that the bugs can be subtle and easily missed for a long time.
  - gravypod 11y ago
    Yes, but from what I understand this bug is more commonly introduced in code that is being updated. Notice that I said "avoided", not "fixed". That is because I am rather focused on making code that is maintainable. I posted this original comment to have a dialogue about something I include in my programming practices. I wanted to see how other people viewed this as a development technique.
    - MichaelBurge 11y ago
      You didn't say it explicitly, but your original comment came off more like "This option is unnecessary and should be removed from gcc, since we can simply enforce a style of using curly braces everywhere" C doesn't do this, but I like this feature from Perl for single-statement checks: return if is_red($traffic_light); return unless is_green($traffic_light); In C, I usually put the early returns on their own line without curly braces, but place them all together at the start of the function to make it easier to spot inconsistencies.
      - kbenson 11y ago
        I love that feature of Perl, and to be explicitly clear to those that are unfamiliar with it, Perl does not allow unbraced single line if's in the normal sense (pre-conditional ifs), and does not allow braced post-conditional ifs. For example, these are valid: if ( $foo ) { bar(); baa(); } quux() if $foo; And these are not: if ( $foo ) bar(); { bar(); baz(); } if $foo;

gravypod 11y ago

No. That is not what I mean. If you look at my response to iainmerric you will see that I don't feel you should change code that is working. This type of bug is largely introduced from someone who is going in and changing a section of code. My philosophy is that if you are editing a section of code, you should update the braces in that section along with your current patch. Over time you see a larger and larger drop in these kinds of bugs as people always, on my team due to the habit of fixing braces and a matching drop from outside contributes due to a larger and larger portion of the code matching the style guide.

mikeash 11y ago
That seems like a somewhat different case, though. Your approach will help prevent new bugs like this from being introduced, but won't help you against existing examples of it in areas you're not currently working on. And just because it's been around a long time doesn't mean it's "working." Goto fail showed that the bugs can be subtle and easily missed for a long time.
- gravypod 11y ago
  Yes, but from what I understand this bug is more commonly introduced in code that is being updated. Notice that I said "avoided", not "fixed". That is because I am rather focused on making code that is maintainable. I posted this original comment to have a dialogue about something I include in my programming practices. I wanted to see how other people viewed this as a development technique.
  - MichaelBurge 11y ago
    You didn't say it explicitly, but your original comment came off more like "This option is unnecessary and should be removed from gcc, since we can simply enforce a style of using curly braces everywhere" C doesn't do this, but I like this feature from Perl for single-statement checks: return if is_red($traffic_light); return unless is_green($traffic_light); In C, I usually put the early returns on their own line without curly braces, but place them all together at the start of the function to make it easier to spot inconsistencies.
    - kbenson 11y ago
      I love that feature of Perl, and to be explicitly clear to those that are unfamiliar with it, Perl does not allow unbraced single line if's in the normal sense (pre-conditional ifs), and does not allow braced post-conditional ifs. For example, these are valid: if ( $foo ) { bar(); baa(); } quux() if $foo; And these are not: if ( $foo ) bar(); { bar(); baz(); } if $foo;