5 ms·

I'll never understand why people would rather complicate things in an attempt to avoid null checks rather than provide null checks.

johncolanduoni 11y ago
Because you can forget a null-check, but the type system won't let you forget an option/not_null? It's the same reason we complicate things with type systems in general.
- halayli 11y ago
  It's more for consistency. You can still forget to use a not_null.
  - johncolanduoni 11y ago
    Not if you're calling into an API that uses not_null; it will automatically insert the null check.
    - halayli 11y ago
      My point is that you can easily forget to declare a pointer as not_null and revert back to the old habit of declaring it as int*. The responsibility is still on the programmer.
jschwartzi 11y ago
Yes. Malloc is a really good example of this, where malloc returning NULL indicates a fundamental resource is not available. If you dereference the pointer returned by malloc under those conditions, your program crashes, just like if you were to not catch an exception thrown at instantiation-time with a reference type. You should absolutely use NULL to represent the absence of some fundamental resource, like memory or a device. To the extent that a device is memory-mapped, it's the same thing. NULL is just a tool. It's just a way for you to express some property of your API. That said, some of the strategies outlined in the article could be very useful for avoiding use of pointers. Use of a class type implementing an interface as a "null type" is a very good strategy. Such a type could guarantee successful instantiation, and so avoid the need to throw exceptions or otherwise crash entirely. You could architect an application with those strategies and completely avoid the use of NULL and nullptr entirely. But where your program is dependent on a finite resource, you must have a way to represent the absence of that resource. NULL and nullptr are convenient ways to do that without a ton of extra code. So no, don't avoid NULL.
- aidenn0 11y ago
  Dereferrencing NULL will not always cause your program to crash.
  - mikekchar 11y ago
    You have intrigued me, as what you say is true, but I wish you would elaborate. There are some architectures for which dereferencing an address of 0 does not cause an exception. If you are writing code for those architectures (or code that is meant to be portable), then you can't rely on dereferencing NULL to crash. This is universally well known amongst programmers who work on those architectures. It's been more than a decade since I did any C/C++, so I wonder if you were referring so something else that I'm not aware of.
    - saurik 11y ago
      Generally it is not an "architecture" that makes this fail, it is a property of the operating system or even only the linker. If you look at a Mach-O executable on OS X, you will see a __PAGEZERO segment that explicitly causes the dynamic linker to put an invalid block of memory at address 0: for backwards compatibility reasons, in 32-bit processes, without that totally optional load command, and even with that command if you choose to override it at runtime using mmap or any number of mach memory management functions, you can allocate memory at that address. (Apple mitigates this in 64-bit processes by having the operating system disallow mapping memory to this location.) In fact, this is a technique commonly used in many kernel exploits on both Linux and OS X, and was even used just a few months ago in the "tpwn" exploit of OS X 10.10.5, prompting the researcher who disclosed that vulnerability to also release NULLGuard, whose entire purpose is to help protect your system by disallowing processes from executing if they are missing a __PAGEZERO segment. https://github.com/kpwn/NULLGuard https://github.com/kpwn/NULLGuard
      - dllthomas 11y ago
        It can also be the compiler. If it observes you dereferencing a pointer, it can elsewhere assume that pointer is not null. If that's not the case, things can get messy.
aidenn0 11y ago
Because people forget to provide null checks.

johncolanduoni 11y ago

Because you can forget a null-check, but the type system won't let you forget an option/not_null? It's the same reason we complicate things with type systems in general.

halayli 11y ago
It's more for consistency. You can still forget to use a not_null.
- johncolanduoni 11y ago
  Not if you're calling into an API that uses not_null; it will automatically insert the null check.
  - halayli 11y ago
    My point is that you can easily forget to declare a pointer as not_null and revert back to the old habit of declaring it as int*. The responsibility is still on the programmer.

jschwartzi 11y ago

Yes. Malloc is a really good example of this, where malloc returning NULL indicates a fundamental resource is not available. If you dereference the pointer returned by malloc under those conditions, your program crashes, just like if you were to not catch an exception thrown at instantiation-time with a reference type. You should absolutely use NULL to represent the absence of some fundamental resource, like memory or a device. To the extent that a device is memory-mapped, it's the same thing. NULL is just a tool. It's just a way for you to express some property of your API. That said, some of the strategies outlined in the article could be very useful for avoiding use of pointers. Use of a class type implementing an interface as a "null type" is a very good strategy. Such a type could guarantee successful instantiation, and so avoid the need to throw exceptions or otherwise crash entirely. You could architect an application with those strategies and completely avoid the use of NULL and nullptr entirely. But where your program is dependent on a finite resource, you must have a way to represent the absence of that resource. NULL and nullptr are convenient ways to do that without a ton of extra code. So no, don't avoid NULL.

aidenn0 11y ago
Dereferrencing NULL will not always cause your program to crash.
- mikekchar 11y ago
  You have intrigued me, as what you say is true, but I wish you would elaborate. There are some architectures for which dereferencing an address of 0 does not cause an exception. If you are writing code for those architectures (or code that is meant to be portable), then you can't rely on dereferencing NULL to crash. This is universally well known amongst programmers who work on those architectures. It's been more than a decade since I did any C/C++, so I wonder if you were referring so something else that I'm not aware of.
  - saurik 11y ago
    Generally it is not an "architecture" that makes this fail, it is a property of the operating system or even only the linker. If you look at a Mach-O executable on OS X, you will see a __PAGEZERO segment that explicitly causes the dynamic linker to put an invalid block of memory at address 0: for backwards compatibility reasons, in 32-bit processes, without that totally optional load command, and even with that command if you choose to override it at runtime using mmap or any number of mach memory management functions, you can allocate memory at that address. (Apple mitigates this in 64-bit processes by having the operating system disallow mapping memory to this location.) In fact, this is a technique commonly used in many kernel exploits on both Linux and OS X, and was even used just a few months ago in the "tpwn" exploit of OS X 10.10.5, prompting the researcher who disclosed that vulnerability to also release NULLGuard, whose entire purpose is to help protect your system by disallowing processes from executing if they are missing a __PAGEZERO segment. https://github.com/kpwn/NULLGuard https://github.com/kpwn/NULLGuard
    - dllthomas 11y ago
      It can also be the compiler. If it observes you dereferencing a pointer, it can elsewhere assume that pointer is not null. If that's not the case, things can get messy.

aidenn0 11y ago

Because people forget to provide null checks.