In this case. It would be better to ensure all SQL is properly escaped, but because that isn't a trivial task, instead you end up adding another layer of complexity.
Then consider the downside and cost of filtering the input, vs. the downside and cost of injection attack times a probability of 0.01% of a developer messing up -- and a policy, however idiotic it may seem to the individual developer, may make sense on a business level.
Sometimes adding a second line of defense at 90% efficiency is cheaper than increasing the first line from 90% to 99%.
function normalise(s) {
return (s + "").toLowerCase();
}
function isEqual(a, b) {
return normalise(a) == normalise(b);
}
if (isEqual(surname, null)) {
return error;
}The problem with data destruction is that only one thing in the entire data pipeline has to spuriously map two distinct values to the same output value, and the data is destroyed and can not be recovered. Very few programmers think carefully about whether a serialization or data transfer format maps every single possible input to a different output. It may only take one oversight to ruin your year.
null is coerced to "null" when it's needed as a string. This behaviour is similar to printf in C. It's not the case that "null" === null like True == 1 in Python. (This would be my interpretation of "x is represented by y".)
>>> typeof null
object
>>> typeof "null"
string
>>> typeof (null + "")
string
#1 arguably makes sense. Unless "null" were a "type" (which it isn't), the other possible options for this ("undefined", or "string", "number", "array", etc.) all make less sense.
#2 is expected/correct.
#3 makes sense if you accept that the "+" operator aggressively casts its arguments to strings when they are anything other than two numbers. Arguably that's a bad design, but it's not unexpected or unpredictable.
The one completely unexplainable "+" behavior I know of in JS (i.e., a recent node/v8) is the second of these:
> [] + {}
'[object Object]' // makes sense because the string representation of [] is ''
> {} + []
0 // ???
> var x = {} + []
undefined
> x
'[object Object]' // but assigning to a variable first makes sense again`typeof` gets the primitive type of a value, and exactly like undefined null is a primitive value with its own primitive type, as `typeof undefined` returns `"undefined"` `typeof null` was supposed to return `"null"`, it doesn't due to a bug in the original implementation which was then spec-enshrined as fixing it would break too much stuff: http://www.2ality.com/2013/10/typeof-null.html
> [] + {}
Becomes:
> [].toString() + {}.toString()
Empty array to a string is "" (empty string). Object to string is "[object Object]".
> {} + []
Becomes:
> +[]
The prefix turns the array into a number, same as Number([]). This seems to be because {} is interpreted as a code block, not an object, due to it being the first thing.
Put it in parentheses and it'll do toString like before.
Edit: And a comment nearby explains that it is the way it is for the same reason Make barfs on leading spaces. Well, at least that's a reason! A terrible, terrible reason.
http://stackoverflow.com/questions/4456438/how-to-pass-null-...
Edit: IIRC there was a directive that would prevent the behavior though?
Edit: whoops, forgot the one time I wrote a one-off Mac app in Swift.
Side note: please refrain from "sounds like someone doesn't understand". It is extremely condescending, dissuades discussion by most people whether they actually know the topic or not, and can be especially deflating to people who are less educated but currently learning.
If there is something that you feel I misunderstood about the way popular languages treat the string `"null"`, feel free to explain it (there are many other response comments I've gotten that are good examples). But if the purpose of your comment is to make me or anyone else feel ignorant, please just keep it to yourself.