3 ms·

In database speak, if your function takes nullable values it is "denormalized". If you design your data structures and flows right, you really don't have many o

In database speak, if your function takes nullable values it is "denormalized". If you design your data structures and flows right, you really don't have many of these. > False. A null pointer dereference in C is undefined behaviour and can therefore easily be a security flaw (there's been at least one local root vulnerability in Linux due to this). Yes. in theory... and yes I heard there are also some stupid compiler optimizations around this. Still, the point is, what do you get from checking for a condition that shouldn't happen? At most an assert is justified! You don't check for the infinitely many other conditions that shouldn't happen, either.

lmm 9y ago
> If you design your data structures and flows right, you really don't have many of these. So it's really important to be able to tell which ones they are! > what do you get from checking for a condition that shouldn't happen? At most an assert is justified! An assert is a check, still takes up a lot of reading time if you have to do it for every parameter on every function. > You don't check for the infinitely many other conditions that shouldn't happen, either. I check for all the things that the code allows to happen, because sooner or later they will happen. You have to do this if your code ever accepts user input; any input that is possible will, sooner or later, find its way in. So if something shouldn't happen the best course is to make it impossible in the code.
- jstimpfle 9y ago
  > I check for all the things that the code allows to happen, because sooner or later they will happen. So if you know it will happen, why don't you fix the bug instead of "recovering"? > So if something shouldn't happen the best course is to make it impossible in the code. Exactly what I was suggesting. But adding a check is not "making it impossible". You need to go to the call site and fix the invalid call.
  - lmm 9y ago
    Code changes all the time; you can fix the calls you know about, right now, but you're relying on everyone who calls your function to infer some extra context about it and get it right every time. The defect will keep reoccurring. Whereas if you make it part of the function's type that it can't be called that way, then the compiler enforces that it will be used correctly, automatically, and you never have to fix the same problem again.
    - jstimpfle 9y ago
      That's programming. Defects come (and often stay) as you type. Yes, it would help a tiny little bit if the compiler would check for nullable pointers. But this comes at a cost of annotation work / maintenance work / worse modularity, and it only helps a bit. There are so many more invariants (is this integer in the range 3-42 and odd or divisible by 12, is that integer a valid index into this other dynamic array...) that you can't practically check with a static system, and they are much much worse because many of them manifest themselves in much subtler ways. All these formalisms work in some toy examples, but adhering to them makes a big mess as soon as it gets a little more complicated. Most basic example, const. I use const almost only for pointers to static const strings, because otherwise it always ends up in a big mess somehow (because const in one place is non-const in another place, guaranteed). And let's not talk about the const-mess in C++ where so many functions are duplicated just for const, without any pracitcal benefit. I probably wouldn't mind a very light-weight opt-in guarantee-not-null syntax. But it doesn't matter for me, at all.
      - aninhumer 9y ago
        >There are so many more invariants [...] that you can't practically check with a static system You can't statically check the invariants directly, but you can make types that statically enforce that the invariants are dynamically checked. That way you can be sure your assumptions hold when the data gets to your code, and any invalid data will be recognised as such, rather than manifesting as weird behaviour.
        jstimpfle 9y ago

lmm 9y ago

> If you design your data structures and flows right, you really don't have many of these. So it's really important to be able to tell which ones they are! > what do you get from checking for a condition that shouldn't happen? At most an assert is justified! An assert is a check, still takes up a lot of reading time if you have to do it for every parameter on every function. > You don't check for the infinitely many other conditions that shouldn't happen, either. I check for all the things that the code allows to happen, because sooner or later they will happen. You have to do this if your code ever accepts user input; any input that is possible will, sooner or later, find its way in. So if something shouldn't happen the best course is to make it impossible in the code.

jstimpfle 9y ago
> I check for all the things that the code allows to happen, because sooner or later they will happen. So if you know it will happen, why don't you fix the bug instead of "recovering"? > So if something shouldn't happen the best course is to make it impossible in the code. Exactly what I was suggesting. But adding a check is not "making it impossible". You need to go to the call site and fix the invalid call.
- lmm 9y ago
  Code changes all the time; you can fix the calls you know about, right now, but you're relying on everyone who calls your function to infer some extra context about it and get it right every time. The defect will keep reoccurring. Whereas if you make it part of the function's type that it can't be called that way, then the compiler enforces that it will be used correctly, automatically, and you never have to fix the same problem again.
  - jstimpfle 9y ago
    That's programming. Defects come (and often stay) as you type. Yes, it would help a tiny little bit if the compiler would check for nullable pointers. But this comes at a cost of annotation work / maintenance work / worse modularity, and it only helps a bit. There are so many more invariants (is this integer in the range 3-42 and odd or divisible by 12, is that integer a valid index into this other dynamic array...) that you can't practically check with a static system, and they are much much worse because many of them manifest themselves in much subtler ways. All these formalisms work in some toy examples, but adhering to them makes a big mess as soon as it gets a little more complicated. Most basic example, const. I use const almost only for pointers to static const strings, because otherwise it always ends up in a big mess somehow (because const in one place is non-const in another place, guaranteed). And let's not talk about the const-mess in C++ where so many functions are duplicated just for const, without any pracitcal benefit. I probably wouldn't mind a very light-weight opt-in guarantee-not-null syntax. But it doesn't matter for me, at all.
    - aninhumer 9y ago
      >There are so many more invariants [...] that you can't practically check with a static system You can't statically check the invariants directly, but you can make types that statically enforce that the invariants are dynamically checked. That way you can be sure your assumptions hold when the data gets to your code, and any invalid data will be recognised as such, rather than manifesting as weird behaviour.
      - jstimpfle 9y ago