3 ms·

You've never had a problem with a null pointer in C or C++? Ever? You didn't answer my question, either. What do you think are the most common sources of ins

by gdp 17y ago

You've never had a problem with a null pointer in C or C++? Ever? You didn't answer my question, either. What do you think are the most common sources of instability?

huhtenberg 17y ago
> You've never had a problem with a null pointer in C or C++? Ever? Not once we had a recorded bug caused by calling a class method on a null pointer. If the code is operating with references, it requires some ingenuity to return a null reference from a function. And if the code operates with pointers, the null checks are typically there. So, yeah, the p->foo() with p being null is a very uncommon issue. With regards to what are the common sources of instability are - based strictly on my experience, the "instability" in C++ context typically comes from not enforcing class invariants, or not adhering to the declared class semantics. This clearly can come in a variety of forms and shapes, and it is hardly possible to pinpoint specific language construct as a single most common root of these problems. Also, I frankly do not remember when was the last time we had an actual crash in our production code. In C context the sources of crashes vary, but more often than not they are caused by the side effects of the functions, i.e. you have a data structure (pointed at or allocated in some other fashion), you feed it to the function and this call invalidates it, but you assume it does not. This sort of thing. Again, if there are pointers, then any C programmer worth his salt will have either an assert or a conditional right after where this pointer is initialized or changed. I have never seen a bug caused by calling a null function pointer, and there is some code that makes a very extensive use of them. Hopefully this answers your question. Now, how about the link to that article ?
- gdp 17y ago
  This is what I was thinking of (I misspoke, it's a presentation, rather than a paper), but I recall seeing more than just an abstract somewhere. Perhaps I was reading commentary: http://lambda-the-ultimate.org/node/3186 http://lambda-the-ultimate.org/node/3186 From what you've said, it sounds like your code (and perhaps team?) are better than average. You say yourself, you haven't had an actual crash since you can remember. If you were having crashes, then my money would be on them being caused by one of: null references (which generally just falls into the category of "not checking return values") and not accounting for edge cases. But you don't have crashes, so all of this is a little bit speculative, isn't it?

by gdp 17y ago

You've never had a problem with a null pointer in C or C++? Ever? You didn't answer my question, either. What do you think are the most common sources of instability?

huhtenberg 17y ago

> You've never had a problem with a null pointer in C or C++? Ever? Not once we had a recorded bug caused by calling a class method on a null pointer. If the code is operating with references, it requires some ingenuity to return a null reference from a function. And if the code operates with pointers, the null checks are typically there. So, yeah, the p->foo() with p being null is a very uncommon issue. With regards to what are the common sources of instability are - based strictly on my experience, the "instability" in C++ context typically comes from not enforcing class invariants, or not adhering to the declared class semantics. This clearly can come in a variety of forms and shapes, and it is hardly possible to pinpoint specific language construct as a single most common root of these problems. Also, I frankly do not remember when was the last time we had an actual crash in our production code. In C context the sources of crashes vary, but more often than not they are caused by the side effects of the functions, i.e. you have a data structure (pointed at or allocated in some other fashion), you feed it to the function and this call invalidates it, but you assume it does not. This sort of thing. Again, if there are pointers, then any C programmer worth his salt will have either an assert or a conditional right after where this pointer is initialized or changed. I have never seen a bug caused by calling a null function pointer, and there is some code that makes a very extensive use of them. Hopefully this answers your question. Now, how about the link to that article ?

gdp 17y ago
This is what I was thinking of (I misspoke, it's a presentation, rather than a paper), but I recall seeing more than just an abstract somewhere. Perhaps I was reading commentary: http://lambda-the-ultimate.org/node/3186 http://lambda-the-ultimate.org/node/3186 From what you've said, it sounds like your code (and perhaps team?) are better than average. You say yourself, you haven't had an actual crash since you can remember. If you were having crashes, then my money would be on them being caused by one of: null references (which generally just falls into the category of "not checking return values") and not accounting for edge cases. But you don't have crashes, so all of this is a little bit speculative, isn't it?