Greg writes:

> While not allowed as its own entity, there was some traffic months ago
>  on rolling your own nulls with negative zero. For strings or non-numeric
>  data, one could use some other convention, such as low-values.
>  Unfortunately, this can bite back, but it is possible to use such a
>  convention for the complete absence of value (insert joke here).

While I joked around in my first response to Costas' question, Greg's response
is much more appropriate. Null entries, although never officially defined
anywhere, already exist in IMAGE for text items. In both IMAGE and Query, an
undefined text field is filled with binary zeros, not blanks, thus it has all
of the qualities of a NULL. A field filled with blanks is not equivalent to a
field filled with binary zeroes. One has a specific value; the other has an
non-defined (or not yet defined) quality to it.

Similarly, the idea of negative zeroes representing nulls is an old one.
Languages such as BASIC use a negative zero (or more accurately, the largest
negative number the range will support) as a NULL. For example, the bit
pattern for such a NULL would be: 10000000, if the word size was 8 bits (and
would thus be equivalent to a -128). Doing this clearly eliminates one data
value from the total range of all expressable values, but that would be true
in any case for any representation of nulls.

While IEEE reals have various forms of null values already defined as part of
their specifications, the other IMAGE datatype forms don't. But there are
ready suggestions. A null should be a bit pattern that is otherwise "illegal",
thus a field filled with binary zeroes makes a perfect (and perfectly obvious)
NULL definition for X, U, P, and Z datatypes.

Similarly, a negative zero (max negative number) makes a good NULL for I, J,
K, and R datatypes (with a max negative being especially good for J datatypes
because it too is an illegal bit pattern).

Wirt Atmar