4 ms·

It's non-obvious that asserts would just be #define'd out of existence when NDEBUG is defined if you haven't been told that specifically.

to3m 15y ago
As you might be told specifically by, for example... the documentation?! The biggest surprise for me is that this error survived more than one attempt to remove it...
- Swannie 15y ago
  Doesn't surprise me if it's in a 20k loc program. Very easy to overlook the obvious. That said, like the previous comments, if someone had seriously looked for this issue, you'd have hoped they'd have found this pretty quickly.
  - to3m 15y ago
    No, that's a fair comment. I have spent a surprising proportion of the past 10 years moving initialization calls from <random problem-causing place> into `main', so whenever I see a call to something like `someinitialization' I just assume it's in `main' along with all of the rest of them. But it could easily be somewhere creepy and random, and the side-effects a bit hard to spot, making it harder to find. (Which, of course, is why you should always put all of this stuff in `main' ;)
leot 15y ago
Why bother having assert statements at all in a language if they're going to stick around in production code? If you're actually worried about something actually going wrong you shouldn't be looking to an assert statement (but, instead, probably a straight condition).
- alexgartrell 15y ago
  Asserts are useful because they blow up when the impossible happens, which greatly simplifies finding the problem later. Why is this a bad idea when the impossible happens in production code? In fact, many projects (such as Google Chrome/V8, in src/v8/src/checks.h and src/v8/src/checks.cc) deliberately provide a persistent alternative to assert so that it can be used in production code. I'm not arguing that asserts should stick around forever, but it's obvious that there's at least an occasional need for something like assert in production code, and so it's not as straightforward as you suggest for someone who has never been told to jump to the correct conclusion.
  - leot 15y ago
    I was under the impression that asserts are different from run-of-the-mill error checking and handling. In particular, they don't usually let you do anything if they fail, and simply cause the program to (informatively) terminate. But that said I don't have tons of experience with large projects.

to3m 15y ago

As you might be told specifically by, for example... the documentation?! The biggest surprise for me is that this error survived more than one attempt to remove it...

Swannie 15y ago
Doesn't surprise me if it's in a 20k loc program. Very easy to overlook the obvious. That said, like the previous comments, if someone had seriously looked for this issue, you'd have hoped they'd have found this pretty quickly.
- to3m 15y ago
  No, that's a fair comment. I have spent a surprising proportion of the past 10 years moving initialization calls from <random problem-causing place> into `main', so whenever I see a call to something like `someinitialization' I just assume it's in `main' along with all of the rest of them. But it could easily be somewhere creepy and random, and the side-effects a bit hard to spot, making it harder to find. (Which, of course, is why you should always put all of this stuff in `main' ;)

leot 15y ago

Why bother having assert statements at all in a language if they're going to stick around in production code? If you're actually worried about something actually going wrong you shouldn't be looking to an assert statement (but, instead, probably a straight condition).

alexgartrell 15y ago
Asserts are useful because they blow up when the impossible happens, which greatly simplifies finding the problem later. Why is this a bad idea when the impossible happens in production code? In fact, many projects (such as Google Chrome/V8, in src/v8/src/checks.h and src/v8/src/checks.cc) deliberately provide a persistent alternative to assert so that it can be used in production code. I'm not arguing that asserts should stick around forever, but it's obvious that there's at least an occasional need for something like assert in production code, and so it's not as straightforward as you suggest for someone who has never been told to jump to the correct conclusion.
- leot 15y ago
  I was under the impression that asserts are different from run-of-the-mill error checking and handling. In particular, they don't usually let you do anything if they fail, and simply cause the program to (informatively) terminate. But that said I don't have tons of experience with large projects.