It Really Sucks To Be Named Jennifer Null

It Really Sucks to Be Named Jennifer Null

Once upon a time, the worst names to be named were things like Hugh Jass and I.P. Freely. But that all changed when we started living our lives on the internet.

A BBC story looks into some names that you don't want to have in our hyperconnected world, and topping them all is the name of a woman in Virginia named Jennifer. Her full name is Jennifer Null:

When Jennifer Null tries to buy a plane ticket, she gets an error message on most websites. The site will say she has left the surname field blank and ask her to try again.

Instead, she has to call the airline company by phone to book a ticket -- but that's not the end of the process.

"I've been asked why I'm calling and when I try to explain the situation, I've been told, 'there's no way that's true'," she says.

Apparently Null has trouble getting into the IRS's site, and had problems with her utility bill as well. I guess that's what happens when your name is a programming placeholder for "nothing."

What's worse is that this is not her maiden name: Null willingly put herself into this situation by taking her husband's name when she got married. And they have a child, so it's something that something Little Null will have to live with forever as well. Thanks for Null, mum.




    lol such random screenshot. If we are talking about SQL Server, and we may well be, NULL isn't actually nothing....null is unknown....null could be something....or it could be nothing...the point is you don't know.

      Null meaning unknown is true from the data use perspective, but as far as three-value logic goes it's more accurate to refer to it as 'no value'. As far as the database is concerned, null is the non-value nothing (literally in the case of variable width columns, nothing at all is stored) as distinct from a data value of nothing (eg. zero, empty string, empty collection) which do actually have bytes stored.

    This seems highly unlikely unless the website is poorly coded (and open to SQL injection attacks). Any decent website would hold the name fields in strings and pass it to the database in same fashion, likely through a parametrised SQL statement. It's the difference between a programming null value and the string value "null", the two are not equal or interchangeable.

      Try it yourself, the word 'null' breaks a lot of input fields, especially on website forms.

        To be fair, most websites are written by people who have no idea what they're doing. Just look at the odd 99% of sites that serve XHTML markup through the text/html MIME type without realising it doesn't accomplish anything. As long as the word 'NULL' is properly quoted, most all SQL servers handle it fine.

        It really shouldn't if the input is properly validated/escaped. I would expect if things are done properly then the value passed is " 'null' " or " "null " " - if it's quoted it should be treated like any other string and not a null operator. I once spent hours trying to figure out a problem I had caused myself by updating a value to 'null' instead of null. OMG pain.

          Null is not an operator in any language I've ever encountered and string escaping shouldn't be part of any solution involving handling of null values. Ever. If it is, you have bigger problems.

    And this is what happens when you have business requirements designed by a programmer.

      No, it is what happens when programmers don't know what they are doing. 'Null' is not equivalent to a null value.

      No, it's what happens when your code is written by someone who doesn't know what they're doing. "NULL" != NULL. Nothing to do with design or requirements.


          Although I would have said 'null' <> null. That said I am a database developer so taking that into account 'null' <> null wouldn't even be a valid operation because you can't compare things to null.

            Yeah, SQL misses some of the nicer features of full-fledged languages. It doesn't gain any benefit from Yoda conditions either, and I'm not sure I can ever love a language that doesn't benefit from Yoda conditions.

              Google yoda conditions I had to. Interesting it was.

              Could you elaborate on what features SQL is missing with regards to treatment of nulls?

                Covered mostly in my answer below, but the inability to include null on either operand of a binary operator is absent in SQL but present in all full-fledged languages that I'm familiar with.

            The predicate 'null' <> null is a perfectly valid comparison in SQL - as a database developer you should know that - it will just always evaluate to false. A predicate that is false under all interpretations of a model isn't invalid, it's just contradictory.

            I suspect part of the problem is that languages like C do treat NULL as a comparable constant with a defined value: this has its own issues and is why SQL has a different operator for checking if a value is null.

              Im not sure I agree with you. A predicate can evaluate to true, false or unknown. If it always evaluates to false...can you validly call it a predicate? In any case that is probably just semantics. As it always evaluates to false, it is not what I would call a valid comparison.... Seeing as it isn't able to compare anything. Syntactically valid? Sure... Logically? No... It can't serve any purpose that a constant false couldn't fulfill.

                And if I saw anyone do it in production code I would probably slap them!

                You're probably right if you assume that you are comparing directly against the keyword null (as in 'Null' <> null), but don't forget that the right-hand operand of that expression could be a function or a column (as in 'Null' <> f(a)c, where f(a) may return a value or it may return null.

                In the latter case, depending on the definition of f it may not necessarily be a contradiction.

              In SQL, comparing against NULL doesn't evaluate to false, it evaluates to NULL, indicating an unknown value. This is defined in section 8.2 of the SQL-92 specification, where X and Y are variables or row elements and XV and YV are their respective values:

              a) If XV or YV is the null value, then "X <comp op> Y" is unknown.

              An unknown result is not the same as a false result, nor is it a valid result. The reason you might see false being returned from a query like that is because it's trying to shoehorn the third state in ternary logic into a bivalent response - that is, the condition evaluates to 'not true' which is synonymous with 'false' in bivalent logic but is expressly not so in ternary logic.

              There's no logical problem with using null in any operand of a binary operator, the main risks are null pointer assignment (using = instead of ==) and null pointer access caused by null being in the left operand position. Both are avoided with Yoda conditions in any typical programming language.

              SQL doesn't experience either problem so there's no reason to use separate syntax for null comparisons. There's no reason it can't support comparisons of NULL against itself (true) or against any non-null value (false) but the specification doesn't allow it. The way the spec is worded makes it seem like an oversight than an intentional design decision.

              (Edited to fix the angle brackets in the quote being stripped out. A bit sad in a conversation about correctly quoting and escaping values!)

              Last edited 28/03/16 1:03 am

                Well NULL in languages like C is very different to in SQL, as the value of null in C exists within the data Domain (for example, 0 for a pointer). In many languages, performing arithmetic operations or comparisons on a null value isn't an issue because a value is present - it's just a magic value that's well defined to mean null. A null pointer doesn't not have a value, it just has a value (typically) of zero.

                Now suppose that the "is null" syntax was removed from SQL and the expression 'x = null" evaluated to true for any value where x is null. Now suppose that a join is performed between two tables that contain null values, but we wish to exclude rows where column a is null in both tables:

                Currently, this would be expressed as:
                Select * from x join y where x.a = y.a

                Without "is null":
                Select * from x join y where x.a = y.a and x.a <> null and y.a <> null

                Is this what you were getting at?

                Also, under such a proposal, where null = null, how would set operations work in terms of determining set membership?

                  Implicit logic is usually a bad thing since it requires the developer have foreknowledge of the language's idiosyncrasies. Explicit logic is better, even if it means the statement is longer. The null exclusion in the first statement is implicit and may not be desired in some circumstances, whereas it's explicit in the latter (though I'd prefer if the language supported a 'not equals' operator like != directly rather than using <> which turns 'x <> y' into 'x < y OR x > y' which is two additional instructions. Yeah, != does exist but it's not SQL-92 or ANSI compliant).

                  Can you give an example of a set membership test in existing SQL so I know what you're referring to in the last question?


                  This is a contentious issue and debate has raged about it for decades. I don't disagree with your points and I can see merits to both sides of the argument.

                  On the face of it, the treatment of nulls in SQL breaks the reflexive property of equality - but that assumes that the "null" symbol represents the same mathematical object. For example, is it fair to say that ∞ = ∞ is true? After all, although the symbols are the same. I would argue in that example that the ∞ does not represent the same mathematical object in both operands, and I would say the same applies in the treatment of nulls. The same could be said for non-deterministic functions like rand().

                  By way of a very simple example, let's say we have a function that returns the age of a person, however we do not know the ages of anyone. If we allow reflexive equality on null (that is, x = null to evaluate to true as you suggested), then

                  age(zombiejesus) = age(lee)

                  would evaluate to true, which may be incorrectly interpreted as both lee and zombiejesus being the same age which would be an invalid conclusion. The current behaviour is to return a result of null (unknown), which is much more intuitive.

                  At least SQL Server gives you the choice with its ANSI_NULLS option - because that just makes things clearer for everyone :p

                  Not that this has anything to do with the original problem stated in the article, but I think it's an interesting conversation nonetheless!

                  The problem with infinity represents multiple different things, such that sets (1,2,..,n) and (2,4,..,n) may be said to contain differently-sized infinite number of elements (thanks Cantor). Null doesn't really have the same conceptual problem, it safely maps to 'no value' in all cases I'm aware of.

                  In my view the comparison you mentioned, age(zombiejesus) = age(lee), should evaluate true if the result of both functions is null, and that's the answer you would get in any other language. If you were concerned about excluding unknown values, it should be explicit in the comparison. Checking only one side for null would be necessary:

                  age(zombiejesus) = age(lee) AND age(zombiejesus) != NULL

                In a strongly typed language, functions such as an equality comparator need to have a defined data type for their parameters. In SQL, equality is defined for each of the primitive data types. What data type is a null, and what data types should an equality operator that can handle nulls be defined to accept?

                Codd's Third Rule:
                Rule 3: Systematic treatment of null values:
                Null values (distinct from the empty character string or a string of blank characters and distinct from zero or any other number) are supported in fully relational DBMS for representing missing information and inapplicable information in a systematic way, independent of data type.

                Representing missing data, as opposed to a value that represents missing data.

                  In most languages null is type-compatible with all other non-primitive types, and in some languages it's also type-compatible with primitives. What the equality operator accepts varies because of autoboxing and implicit type conversion, but it's generally the case that any compatible type can be compared with itself, its base types, and null.

                  The conclusion you come to in your last sentence is an implementation detail, irrelevant when it comes to the logical flow. A value indicating null must be stored regardless of the system - whether via a bitset in table metadata, via reference to the 0x00 address, via reference to a global read-only static or any other method, a value exists in the implementation, but the implementation has no bearing on the way null is treated in logic. In all cases null means 'no value' and there's no reason it can't be safely compared in SQL.

        SQL Server Management Studio is particularly heinous in the way it handles null values as strings. For example, to nullify a field via the Data Grid it is necessary to type NULL, which SQL Server Management Studio interprets as "to make null". Of course, this means it is impossible to enter a string of NULL this way.

        Exporting data from SQL Server Management Studio has the same issue in that null values are represented with the string NULL in the exported data. Good luck trying to differentiate between someone who doesn't have a surname and someone who's surname is NULL in that export.

          Lol in SSMS it's a slightly shaded yellow vs white. You definitely have to be paying attention.

          Last edited 28/03/16 12:34 am

          SSMS accepts the 'NULL' string literal just fine, make sure you include the single quotes when entering it. The UI will show the quotes as part of the value but it stores the string without quotes.

          It's very rare to use management tools to manipulate production data directly, though. SQL (the language) has no problem distinguishing a null value from a string literal 'NULL', nor does any implementation I've used before. Issues with inserting a string literal NULL are application-side code errors, not limitations or shortcomings in the technology.

          Last edited 28/03/16 1:00 am

            I agree with your points completely, but I still think it is an awful implementation.

    I've had issues with a friend named Con in the past

    Some things really dont like it.

    I had issues with it in a profile name in Windows XP and I clearly remember Need for Speed Underground crashing immediately if you tried to use it as a profile name.

    Fun Times

Join the discussion!

Trending Stories Right Now