C-like language without NULL?

Hi I was recently watching an old video about how null pointers were开发者_如何学Python a billion dollar mistake. He points out both C# and java as they have run-time checks but don't completely eliminate it enough and this is somewhat understandable. He also points out the C at one point which he feels so sure of is a great problem. I get that null terminated strings, arrays with no length and a few other things are bad (billions of dollars on buffer overflow exploits) but to completely remove null?

Some languages have made null a thing of the past and other languages have attempted at being a replacement for C but I cannot find which language has accomplished both.

If C's null is so bad then why hasn't anyone created it's replacement? i.e. Haskell is nice but cannot operate as a drop in replacement.

There is a reason why it was not replaced, look at it this way, there is such a huge wide base of C programs, thousands upon thousands of code lying around, to create a replacement would cause a lot of grief as the code would have to be updated to reflect the change, as a NULL in the context of a pointer means that the call would have failed and hence return a NULL to signify the condition that the code to deal with the pointer has failed. Also, it is used in the case of FILE * operations, if the file was invalid, NULL would be returned. Imagine the hassle if all those code would be changed, unfortunately, it is part of the ANSI C Standard and therefore a very costly exercise in terms of $$$ to get all this changed to adapt to a new convention for a NULL-replacement.

Have a look at this FAQ on the infamous NULL pointer as found in the C FAQ.

Edit: By the way, 'I get that null terminated strings, arrays with no length and a few other things are bad' That is a wrong way of saying it as you are confusing the two...as Peter Van Der Linden author of 'Expert C Programming - Deep C Secrets', a nul with one l is a '\0', a null with two l is a NULL! No such thing as null terminated, that should have read as nul terminated i.e. '\0' which is a placeholder to signify end of string.

Hope this helps, Best regards, Tom.

The problem with null pointers in C is that when you reference them, the program behaves in undefined ways, which results in the "innumerable errors, vulnerabilities, and system crashes" the presentation mentions. But that doesn't mean the idea of a value that is not a real value is necessarily bad. Many languages contain them; they are called NULL, None, NaN, undef, null, nil, etc. You just need to have a well-defined and robust way to deal with them.

I suppose the reason why a language "like C but doesn't crash on null pointer dereferencing" has not seen wide adoption is that the niche for such a language would be very small. One the one hand, you have systems programming where you (purportedly) need tight control over everything that is going on and cannot afford the compiler inserting an automatic null pointer check at every pointer dereference. On the other hand, there is application and other less performance critical programming, where it's much easier to move up a layer or more of abstraction and forget about pointers altogether, which results in things like Java, C#, Python, and others.

When you say C like, it goes to same direction as others. Scala somehow eliminates nulls using option cases. Still, you can use nulls. Functinal languages have no null problems and side effects but they are not c like. Dynamic languages also have nulls or undefined variables and such. It is a price you need yo pay for c like imho.

Any language which allows for things like arrays of pointers must allow for the fact that it may be necessary to read some elements before a sensible value can be ascertained for some others. This raises the possibility than code might attempt to read from an array element before a sensible value has been ascertained for it. There are three plausible ways of handling this:

1. A compiler may require that every element be written (probably in order) before any can be read; this may waste time writing elements with nonsensical values if sensible ones will not be available until after parts of the array have been read.
2. An attempt to read an array slot which has not been written may trigger an immediate error, without there being any means of testing whether an array slot is valid, or marking an array slot as being invalid (in case code knows that a certain spot which had been written once should not be read until it has been written again).
3. As above, but with explicit methods provided for testing whether an array slot is valid, or for invalidating previously-written slots.
4. An attempt to read an array slot which has not been written or is otherwise invalid will yield a special value which cannot be used for anything except to test validity or to invalidate an array slot or other variable.

While #1 might be nice in some contexts, in many other contexts there isn't any particular value a program could put into array slots which would work better than null.