5 ms·

Null pointers strike again.

• okwhateverdude 1y ago
  More like yolo deploys without proper scaffolding in place to handle SHTF. Also, if your red-button takes 40 minutes and deploys to mitigate anything, it isn't a red-button.
  • tempodox 1y ago
    > Without the appropriate error handling, the null pointer caused the binary to crash. Feature flags are used to gradually enable the feature region by region per project, starting with internal projects, to enable us to catch issues. If this had been flag protected, the issue would have been caught in staging. So some combination of both.
• hardwaresofton 1y ago
  Has there been any confirmation it was golang?
  • rfoo 1y ago
    Pretty sure it's C++. inb4 someone yells Rust. No, your `.unwrap()` happily panics in Rust too.
    • kabdib 1y ago
      you don't even need turing-completeness to write a bug that takes down prod :-)
    • hypeatei 1y ago
      How is panicking the same as dereferencing a null pointer, which is undefined behavior?
      • judofyr 1y ago
        In most situations panicking and deferencing a null pointer leads to the exact same scenario: The binary crashes. You can unwind and catch panics in Rust, but I’m not sure if that would have helped in this scenario as it might have immediately went directly into the fault code again. However, I would assume that the presence of an «unwrap» would have been caught in code review, whereas it’s much harder to be aware of which pointers can be null in Java/C++.
        • junon 1y ago
          > In most situations panicking and deferencing a null pointer leads to the exact same scenario: The binary crashes. This is a false and dangerous misconception people seem to get wrong a lot of the time. There's no guarantee that's the case, especially when working in C where pointers are often subscripted. It's the common behavior that a trap occurs but nothing dictates that's actually what will happen.
          • judofyr 1y ago
            Yes! We’re in absolute agreement here! That’s why I said «most situations» and not «all situations».
    • benmmurphy 1y ago
      but a call to unwrap is usually more explicit than a null pointer dereference when you are reviewing code. if you are deserializing something from an external source and calling unwrap() on some optional fields to convert them to non-option types then this should raise alarm bells. of course maybe everyone agrees the external source should not be sending such data and it goes into prod anyway. but also its possible everyone agrees its worth putting some extra effort into not crashing the process in such a situation because there is too much risk.
      • trealira 1y ago
        >calling unwrap() on some optional fields to convert them to non-option types then this should raise alarm bells Yeah, definitely. And the equivalent without optional types, dereferencing a null pointer, might happen because they don't even realize it could be null in the first place. Not everyone writes "assert(ptr != 0)" every time they assume a pointer isn't null, because it happens frequently (if the code doesn't use references enough, which IIRC happens with Google). When you have an option type, you're made aware of it explicitly, and calling `.unwrap()` should, like you said, raise alarm bells and make you think anout whether you actually want to crash the program.
    • IshKebab 1y ago
      Unwrap can definitely bring down a Rust program but it's definitely not nearly as bad as null pointers in C, C++, Java, etc. 1. You have to explicitly add `unwrap()`, in C you just have to forget to add a null check which is a lot easier to do. The compiler won't remind you like it does in Rust. The bug is opt-out-if-you-remember not opt-in-if-you're-lazy. 2. The crash is safe. Usually a null pointer crash is safe but I've definitely seen cases where it leads to impossible-to-debug random failures. 3. You can see `unwrap()`s in code review easily. 4. You can actually catch panics, which is probably a good idea in high availability systems like a web server. I don't know if people actually do this in practice though. Usually it's possible to write similar bugs in Rust but it's also far less likely that you would (though it does definitely happen). So Rust does at least help with this even if it doesn't fully prevent the issue.
• on_the_train 1y ago
  If you write code that crashes on a blank field you'll manage to do that with any language
  • IshKebab 1y ago
    Err yeah but the point is languages without null pointers all over the place make it harder to do that in the first place. You normally get some kind of type error at compile time.
    • ofrzeta 1y ago
      So like "var quota : string | null"? :-)
      • haiku2077 1y ago
        Or quota Optional<string>
      • IshKebab 1y ago
        Yeah. But C++, C, Java and I think even Go don't let you easily encode nullability into the type system. There have been many attempts to fix it (e.g. `@Nonnull` in Java) but none are as good as Typescript or Rust for example. Dart actually started off with implicit nullability and switched to explicit which was a huge effort.
    • on_the_train 1y ago
      There are a lot of ways to prevent this in C++. And all of those which don't would light up static analysis. So as usual, I can't really see the argument.