2 ms·

Sweeping things under the rug just means they'll come back to bite you later, which isn't defensive at all. I did say "known sometimes as". And I've seen a lo

Sweeping things under the rug just means they'll come back to bite you later, which isn't defensive at all. I did say "known sometimes as". And I've seen a lot of "check for NULL and silently replace it by something reasonable so that bugs don't make us crash" code justified as being "defensive". If the security of your code relies on a parameter not being null That's not what I said. Exploit paths may however result in pointers being NULL which are normally non-NULL, and so replacing NULL by "(null)" may turn a denial of service into something worse. Check it explicitly I absolutely agree, developers should use more assertions.

tbrownaw 11y ago
That's not what I said. Exploit paths may however result in pointers being NULL which are normally non-NULL, and so replacing NULL by "(null)" may turn a denial of service into something worse. Exploit paths will likely cause variables to have values outside their expected range. Therefore library functions should be defined as narrowly as possible, in order to convert as many as possible of these cases into crashes. Never mind that this makes the library functions less useful. Never mind that this will push complexity into the caller (or just flat-out add complexity in some cases). Complexity which will necessarily add more opportunities for bugs.
- epidemian 11y ago
  > Never mind that this will push complexity into the caller (or just flat-out add complexity in some cases). Complexity which will necessarily add more opportunities for bugs. I don't follow how this could happen. Is there any other case where printf printing "(null)" for NULL %s values would be useful besides when debugging? If i am debugging then yes, making printf print "(null)" can be useful. But if instead of that it would segfault, the added complexity of doing an explicit check as in printf("%s", str ? str : "(null)") will not "add more opportunities for bugs", because that code won't live past the debugging session. On the other hand, if i'm not debugging, passing a NULL %s value to printf is almost certainly a bug, and i'd much rather have printf segfaulting in the presence of that bug than it silently ignoring it and printing some flag value.

tbrownaw 11y ago

That's not what I said. Exploit paths may however result in pointers being NULL which are normally non-NULL, and so replacing NULL by "(null)" may turn a denial of service into something worse. Exploit paths will likely cause variables to have values outside their expected range. Therefore library functions should be defined as narrowly as possible, in order to convert as many as possible of these cases into crashes. Never mind that this makes the library functions less useful. Never mind that this will push complexity into the caller (or just flat-out add complexity in some cases). Complexity which will necessarily add more opportunities for bugs.

epidemian 11y ago
> Never mind that this will push complexity into the caller (or just flat-out add complexity in some cases). Complexity which will necessarily add more opportunities for bugs. I don't follow how this could happen. Is there any other case where printf printing "(null)" for NULL %s values would be useful besides when debugging? If i am debugging then yes, making printf print "(null)" can be useful. But if instead of that it would segfault, the added complexity of doing an explicit check as in printf("%s", str ? str : "(null)") will not "add more opportunities for bugs", because that code won't live past the debugging session. On the other hand, if i'm not debugging, passing a NULL %s value to printf is almost certainly a bug, and i'd much rather have printf segfaulting in the presence of that bug than it silently ignoring it and printing some flag value.