lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Hi Javier,

Actually the opposite applies. C language handle *REAL* memory directly.
A NULL pointer in C is just a pointer whose value is 0, and 0 is a *REAL* memory address.
Most desktop&servers CPU's will consider an access to the 0 address a programming mistake and raise a SEGFAULT, but that's just a design decision. 0 is just one in a set of forbidden address as many other (upper memory belonging to kernel space  for example or "gaps" between stack segment and code segment).
In fact, in microcontrollers, the "0" address can be read/written normally and it's even possible that some of them use it mapped to I/O ports.

In high-level languages NULL is, as you said, is a separate, single valued type.
What's the utility of such value? There are just two possibilities.
The first one is to declare a variable without forcing to initialize it. For sort programs this can work if we are sure that it will be initialized later on, before reading it.
In bigger programs it's a wrong pattern. A program can always use default values of a given type instead of a NULL, and that automatically fixes many potential errors.

The second use of NULL, is to use it internally (in the Lua VM) as a "mark" to indicate special values like "end of list", "end of parameters", ... This NULL is used just in if conditionals to continue/stop some function.
In such case, it's also possible to replace it with some other more intuitive values. In the lua VM C code for example it would be possible for example, to declare
TValue endOfList;

And later on, just use code like:
if (&objectInstance == endOfList) { /* we are finished reading the list */  ... }

In the Lua VM C code, there is not need to assign any type to those "mark" variables (not need to create a new NULL value), since they will never be read, only its address in memory will be compared, but the code will be more maintanable and easier to read.

The important idea is that nil can always be replaced. It just adds "entropy" to the code. I have a post in my blog explaining the problem with some examples:



On Fri, Jan 9, 2015 at 6:20 PM, Javier Guerra Giraldez <> wrote:
On Fri, Jan 9, 2015 at 12:08 PM, Enrique Arizón Benito
<> wrote:
> For a lot of years I've been interested in a language that fix "the biggest
> bug in History", the invention of null (nil) references

I think this critique only applies to type systems where NULL is a
special value of each type, and in C-like languages using as a pointer
(or reference) can crash the whole program.  calling a design flaw "a
bug" is just sensationalism.

In Lua (and several other dynamic type languages) nil is a separate,
single valued type, you don't have "NULL pointers", not even "NULL
tables" or "NULL numbers"  just that as usual you can get values of
any type at any point.  Not having nil wouldn't avoid you to get a
number when you'd like a table, or viceversa.  you'd still have to
check for boundary cases.