Hacker News Reader

Comment by jmull | Hacker News Reader

I don't get what's happening at the low-level for this to be a problem.

It seems like you'd have to do something pretty stupid at the coding level to introduce a problem with "Null" by mistake. I'm sure it happens, but not more of an occasional issue.

My best guess is that there are common old databases that did not have a first class null type where it was common practice to use the string "NULL" for that purpose. And that companies that have these old systems are proactively filtering user input to prevent causing these old system to choke... It sounds like the filter is case-insensitive, though, which would be too aggressive for the case I'm thinking of. Maybe they are (mis)using a bad word filter for this, which would tend to be aggressive.

View on HN

> My best guess is that there are common old databases that did not have a first class null type where it was common practice to use the string "NULL" for that purpose.

It isn't a DB issue. It's more of a front-end or middle tier issue.

In SQL standards - NULL is a "marker"/TYPE. NULL and "NULL" are two separate things. One is a null type and the other is a string type.

Or more specifically, it is a "interface" problem between RDBMs and front-end since languages handle null differently. Many languages didn't have null types and null in certain languages mean different things that "lack of information".

For example, if a database column was a nullable int column and you wanted to bring it out to the java or .net space you would have issues since "int" in java and .net are value types and not reference types. So you could assigned null to the values. Where as a string/text/varchar column you could since string in java and .net are reference types and can be null.

In some languages, checking for null means you have to convert null into a string and then compare "null" == "null".

It's a legacy of lack of Nullable types in many programming languages. With the introduction of Nullable types many of these problems went away.

I believe the problem might be more common when exporting data from one system to another. I've written code to migrate (and merge) large datasets from old legacy systems. I needed quite a lot of heuristics and "best-effort" transformations in order to deal with data inconsistencies... mostly string manipulations where it's not hard to imagine bugs like this happening.

Ah, so it's your fault. Got it!

;-)

I think JavaScript is the biggest offender here. So this check would fail:

  if (lastName.toLowerCase() != null)

'null' != null in javascript, I'm pretty sure the only thing it weak equals is undefined.

Reply on news.ycombinator.com