Yes I guess that would be more appropriate. Again, it comes down to the "give it the right inputs" argument. At some point you have to trust the user of the function to call it correctly.
Your argument with permutations of inputs is wrong IMO - this argument can be used to claim that any functionality which calls user code (through callbacks, inheritance, whatever, functors) is also defective. Strictly it may be so, but the defectiveness is massively outweighed by the convenience - the most obvious example is calling a late-binding function - but it extends to easier to grasp examples like the C qsort function or EnumWindows in Win32.
Should we not make library calls because the programmer who wrote the library might have, maybe, possibly, screwed us over in some way perhaps, or because the mechanism can be broken with faulty input?
You trust, potentially, the same programmers every time you trust an executable loader to start running your code... which is pretty much every single time.
Aren't you as the person providing the application ultimately responsible for knowledge of what library calls work well and, thus, which you should use? I think Zed's cautionary statements are merely summarizing a bunch of his experiences, ultimately that this library call isn't worth using.
Permutations of input is not "wrong", its a valid mechanism for exposing unexpected/undefined behavior. "Massively outweighed by the convenience" is subjective and, in many circumstances, very suspect.
Your argument does not follow and is an illogical extension. I simply prove that it has a while-loop that won't terminate and use permutations to prove that. The logic proof is valid because I found an instance of the input that would cause it to not terminate.
You can't then extend my argument to mean that all functions should not be called. All functions with unterminated while-loops shouldn't be called, but not all functions.
