People who neither know, nor care, what they’re doing. When you’ve worked with people who are allowed to write code that interfaces with databases for more than about two weeks, you may be dismayed to see the large overlap between those two groups.
Any time "$var" is interpolated without check into an INSERT, and any maintainer finds it easier to just check for null as a string rather than ask a DB admin or committee to update the DB after a lot of red tape and risk assessment.
I don't buy that. The string "Null" is different from the keyword null in programming, so `if $var = null` would be false when $var is the string "Null".
Note that when interpolated into SQL, the contents of $var must be surrounded by single quotes, so you end up with `insert into Table (Name) values ('Null')`, which correctly inserts the string "Null" into the table.
If you were to leave off the quotes, you'd get a SQL syntax error for all other people, so that code would never make it into production. E.g. `insert into Table (Name) values (Smith)` is a syntax error.
I think you underestimate how many systems are stringly-typed, not just in terms of problematic programming languages, but data traveling between different APIs or through literal dead-tree paperwork.
They don't have to all fail at null handling, just one or two can gum up the works.
You can make a good case to spend time sanitising requests to avoid catastrophic failure, but the "null" problem is one that quickly becomes a lot of work and risk to fix after the fact, for no obvious benefit except what's seen as the pedantry of some nerd, so it gets ranked all the way at the back of the list... until someone named Null comes along, and probably still even then.
"System owner, we need to spend $10K to sanitise requests or a kid can destroy our business overnight".
"System owner, we need to spend $10K to clean up the database and code so that null and "null" are not the same thing, even though it works 99.99% of the time".
If there are type confusion bugs related to SQL statements, I think SQL injection is likely to exist, if not some other super nasty bugs will eclipse it.
You can waste 10k paying someone to look at it or you could not waste your money, but I’d be fucked before I sign off on a system with those kinds of bugs as being secure, evidence or not. Someone higher up can accept that risk, but I’d rather not be liable when it’s breached or catastrophically damaged because some kid changed their last name to an SQL injection payload.
And yes, I’ve checked, in my country unpronounceable names are not permitted, otherwise I’d have one. There are existing case studies of this, iirc in the UK.
There’s a few condescending answers here. You will find this more common in weakly typed languages like PHP and VB and maaaaaybe JavaScript, where null == “null” will probably evaluate to true.
js doesn't have this particular problem, but it does have both `null` and `undefined`, which will have varying semantically different usages depending on local conventions.
For example, some will prefer to use `null` to mean that a value is _intentionally_ missing (for example, the db explicitly returned a null value), while `undefined` does not have any such connotation. These exist for frontend engineers to navigate decisions often far removed from their influence.
Anyway, `null != ''` and `null != 'null'`, but `null == undefined`. However, `null !== undefined`.
A lot has been made of js Truthy/Falsy equality operator, but most js programmers will take steps to actively avoid it coming into play. Probably the `void` operator is still under-used though in frontend code, though, since there's some pretty surprising legacy things that can happen when interacting with DOM APIs (like `checkbox.onclick = () => doSomething()` resulting in different checkbox behavior depending on whether or not `doSomething` returns a boolean or undefined).
I would call myself a relatively good developer and I fully understood type checking occurred via ===, and compare by value caught me. In my defence, I assumed this was less of an issue in modern JS, but thou shall not break backward comparability, apparently.
Is this php5 or a more recent version? That is hugely relevant when it comes to pho and something I should have mentioned in my original post (no idea if this specific thing would work in pho5, but there are other weird things)
There's plenty of name=Null, name=Undefined, name=Unknown entries in OpenStreetMap. Some are real places, some are mistakes, not easy to tell especially for restaurants or bars.
Plenty of systems represent all values as strings, and "null" is the obvious (although probably not the best) way to represent a null value as a string.
Which systems do this? I could see situations where reading in a text file, you have might assume the value null is not the string "null". I am struggling to think of other situations.
In C, and many other languages at that, strings are just arrays of bytes.
So you absolutely could store null in a string... It is even a valid ascii and UTF character. Now most string handling functions treat it as the end of a string in C but that is only by convention.
How you would display null to a user is a different story all together but representing it in a string is not an unsolved programming problem, generally its when you need to actually display null that it becomes a hard problem because how do you display the absence of something, specifically when a space is not an absence.
How do you serialise a string... Well it's already serialised given your specific endianness... So you just indicate that... This is 280 bytes of UTF8 data... It can contain as many nulls as you like, until you get 280 bytes of data you don't have all of it.
There is a difference between storing a string with only a null character (i.e. an empty string) and a proper null (i.e. the absense of value). That is what I was getting at when I listed "C strings" as an example.
Since in C strings are quasi-arrays and arrays are quasi-pointers there is probably a way to use a null pointer, but this would be a local convention for getting around C's lack of native support for null values. You couldn't expect it to be supported by utilities or libraries.
I'd guess some data transferred between systems as a homemade CSV. Empty field = empty string, but some field is nullable so someone decided that Null would be a way to declare a null field.
20 years later and multiple systems depending on each others, random hidden CRONs in the middle and now people called Null have a problem.
