61 ms·

How many problems are actually caused by null (in particular, how many billions of dollars?) While pointers which point into the wrong place for various reason

How many problems are actually caused by null (in particular, how many billions of dollars?) While pointers which point into the wrong place for various reasons (off end of array, previously freed memory) cause horrible issues to this day, I can't personally remember ever having a serious issue with a null pointer (they tend to crash quickly and loudly, because in all modern OSes dereferencing NULL segfaults)

FreeFull 14y ago
I don't know about it in terms of money loss, but generally having missed checks caught at compile time rather than having the program crash is a good thing.
- cantankerous 14y ago
  Not to mention lost time spent hunting for a hidden nil value.
spacemanaki 14y ago
> they tend to crash quickly and loudly In some scenarios, this is a serious issue all by itself. My day-to-day work is mostly on Android, and eliminating nullable references altogether would eliminate some crashes, which are highly visible to the user.
cantankerous 14y ago
The problem isn't just NULL in C. This post is talking about the entire Null/Nil reference problem across all languages that use a null-type value. This is especially a problem in dynamic languages that sling nils around....like any major modern scripting language. Checking if a value is nil before proceeding is aping what a language like Haskell does when it pattern matches against Maybe (Just a, Nothing) albeit in a post-facto bad way. Granted, you can't really make any assertions about reflecting a maybe value in the type of a language that doesn't care about types before runtime.
- yew 14y ago
  That's the main problem with calling Maybe 'better'. If you don't have static type checking then either you implement it just for Maybe or you end up with the same sorts of problems as you had before. Making types non-Nullable by default is nice, though. Even in a dynamic language you can have a syntactic distinction to make interfaces more explicit.
  - cantankerous 14y ago
    True. I think it's also a covert argument for static type checking, though ;-).
    - yew 14y ago
      Give me a statically typed Python and a type system that can handle external hardware poking around in its memory and I'm in ;) I'm sort of a fan of Haskell already, to tell you the truth.
      - dllthomas 14y ago
        > Give me a statically typed Python Not sure that's so far from Haskell, really... :-P > and a type system that can handle external hardware poking around in its memory Can it be in isolated places? That's doable...
        yew 14y ago
        Not sure that's so far from Haskell, really... :-P Maybe it's my lack of experience talking. Haskell feels heavier in a lot of places. I think the focus on compilation in the backend is almost a downside here, too. Can it be in isolated places? That's doable... Depends on the application. There's a lot of hardware out there that does really weird stuff. There's some interesting work in Haskell-space (eg Atom) but I don't know how comprehensively mature it is.
      - merijnv 14y ago
        I actually started designing statically typed Python, since it seemed a fun exercise. Halfway in I realised I was effectively redesigning Haskell with slightly different syntax and stopped.
bajsejohannes 14y ago
I've worked with a code base in C++ where the code base would accumulate significant amounts of if (argumentX == null) return null; at the top of function signatures. It was just defensive programming. Maybe argumentX couldn't be null, but it would take time to figure that out (sometimes I did that, though). More code means harder to read and maintain, thus costing dollars. This would also be contagious: If a piece of code checks if X is null, you'll assume that X can be null, whether or not that's true. I'd certainly prefer to be able to reason about the code with the safe assumption that certain things cannot be null.
- josephlord 14y ago
  Even if it can't be null now the calling code may change in the future. And did you check all the possible error conditions (e.g. failed allocation). If you are relying on a non-null call best to check every time.
- kruffin 14y ago
  I'd certainly prefer to be able to reason about the code with the safe assumption that certain things cannot be null. You can do this, but if you want it to be maintainable, you'll also want to detail in the function comments this technical debt. If you don't, someone else will come along and see your sweet method (looking only at the comments) and use it where the input can be null. Ex: /** * This does some stuff. * @param entry Does something with this * DEBT: Assumes the input entry is not null. */ void doSomething(SomeObject entry) { }
  - pubby 14y ago
    Is that C++? Just use a reference if you want a pointer which asserts it can't be null.
    - kruffin 14y ago
      It's Java ;P I haven't used C++ in a long time. But you are correct a reference does exactly what he wants. For anyone who needs to look it up like me: http://en.wikipedia.org/wiki/Reference_(C%2B%2B) http://en.wikipedia.org/wiki/Reference_(C%2B%2B)
deleted 14y ago
[deleted]
qb45 14y ago
There used to be a whole class of Linux vulns involving mmap()ing memory at virtual address 0x0, filling it with fake kernel data structures containing some data value val and some pointer ptr and triggering NULL dereference in kernel code which was known to parse this structure and copy val to address pointed by ptr. They had to "fix" it by blocking userspace memory mappings at the 0th page.

FreeFull 14y ago

I don't know about it in terms of money loss, but generally having missed checks caught at compile time rather than having the program crash is a good thing.

cantankerous 14y ago
Not to mention lost time spent hunting for a hidden nil value.

spacemanaki 14y ago

> they tend to crash quickly and loudly In some scenarios, this is a serious issue all by itself. My day-to-day work is mostly on Android, and eliminating nullable references altogether would eliminate some crashes, which are highly visible to the user.

cantankerous 14y ago

The problem isn't just NULL in C. This post is talking about the entire Null/Nil reference problem across all languages that use a null-type value. This is especially a problem in dynamic languages that sling nils around....like any major modern scripting language. Checking if a value is nil before proceeding is aping what a language like Haskell does when it pattern matches against Maybe (Just a, Nothing) albeit in a post-facto bad way. Granted, you can't really make any assertions about reflecting a maybe value in the type of a language that doesn't care about types before runtime.

yew 14y ago
That's the main problem with calling Maybe 'better'. If you don't have static type checking then either you implement it just for Maybe or you end up with the same sorts of problems as you had before. Making types non-Nullable by default is nice, though. Even in a dynamic language you can have a syntactic distinction to make interfaces more explicit.
- cantankerous 14y ago
  True. I think it's also a covert argument for static type checking, though ;-).
  - yew 14y ago
    Give me a statically typed Python and a type system that can handle external hardware poking around in its memory and I'm in ;) I'm sort of a fan of Haskell already, to tell you the truth.
    - dllthomas 14y ago
      > Give me a statically typed Python Not sure that's so far from Haskell, really... :-P > and a type system that can handle external hardware poking around in its memory Can it be in isolated places? That's doable...
      - yew 14y ago
        Not sure that's so far from Haskell, really... :-P Maybe it's my lack of experience talking. Haskell feels heavier in a lot of places. I think the focus on compilation in the backend is almost a downside here, too. Can it be in isolated places? That's doable... Depends on the application. There's a lot of hardware out there that does really weird stuff. There's some interesting work in Haskell-space (eg Atom) but I don't know how comprehensively mature it is.
    - merijnv 14y ago
      I actually started designing statically typed Python, since it seemed a fun exercise. Halfway in I realised I was effectively redesigning Haskell with slightly different syntax and stopped.

bajsejohannes 14y ago

I've worked with a code base in C++ where the code base would accumulate significant amounts of if (argumentX == null) return null; at the top of function signatures. It was just defensive programming. Maybe argumentX couldn't be null, but it would take time to figure that out (sometimes I did that, though). More code means harder to read and maintain, thus costing dollars. This would also be contagious: If a piece of code checks if X is null, you'll assume that X can be null, whether or not that's true. I'd certainly prefer to be able to reason about the code with the safe assumption that certain things cannot be null.

josephlord 14y ago
Even if it can't be null now the calling code may change in the future. And did you check all the possible error conditions (e.g. failed allocation). If you are relying on a non-null call best to check every time.
kruffin 14y ago
I'd certainly prefer to be able to reason about the code with the safe assumption that certain things cannot be null. You can do this, but if you want it to be maintainable, you'll also want to detail in the function comments this technical debt. If you don't, someone else will come along and see your sweet method (looking only at the comments) and use it where the input can be null. Ex: /** * This does some stuff. * @param entry Does something with this * DEBT: Assumes the input entry is not null. */ void doSomething(SomeObject entry) { }
- pubby 14y ago
  Is that C++? Just use a reference if you want a pointer which asserts it can't be null.
  - kruffin 14y ago
    It's Java ;P I haven't used C++ in a long time. But you are correct a reference does exactly what he wants. For anyone who needs to look it up like me: http://en.wikipedia.org/wiki/Reference_(C%2B%2B) http://en.wikipedia.org/wiki/Reference_(C%2B%2B)

deleted 14y ago

[deleted]

qb45 14y ago

There used to be a whole class of Linux vulns involving mmap()ing memory at virtual address 0x0, filling it with fake kernel data structures containing some data value val and some pointer ptr and triggering NULL dereference in kernel code which was known to parse this structure and copy val to address pointed by ptr. They had to "fix" it by blocking userspace memory mappings at the 0th page.