"null Considered Harmful"

Discussion in 'C Programming' started by Lynn McGuire, Dec 11, 2013.

  1. Just to be clear, the "might be null" and "can't be null" pointer types
    in the post you are replying give you flexibility that references
    don't. (That may be tangential to your point, I was not clear what
    point you were making.)

    Ben Bacarisse, Feb 14, 2014
    1. Advertisements

  2. Lynn McGuire

    Melzzzzz Guest

    Heh, references are invented because of operator overloading.
    Using them instead of pointers is not exactly convenient ;)
    Melzzzzz, Feb 14, 2014
    1. Advertisements

  3. Lynn McGuire

    James Kuyper Guest

    If a pointer's value can be set at the point of declaration, and never
    modified, it's usually quite trivial to change the code to use a
    reference instead; the result is often a substantial simplification of
    the code.
    James Kuyper, Feb 14, 2014
  4. Lynn McGuire

    Kaz Kylheku Guest

    In a C++ program that is known to be "strictly conforming" (the C++ equivalent
    thereof) that is the case. We indirectly know that the program does no such
    thing because we know it to be correct.

    In practice, C++ compilers allow references to be bound to dereferenced null
    pointers, without diagnostics.

    int &ref = *ptr;

    There is C++ code out there which depends on this kind of thing:

    if (&ref == 0) {
    /* reference was bound through a null */
    Kaz Kylheku, Feb 15, 2014
  5. Lynn McGuire

    Ian Collins Guest

    That code would be in the same bucket as C code that uses gets...
    Ian Collins, Feb 15, 2014
  6. Lynn McGuire

    Jorgen Grahn Guest

    It is, but not in the context of comp.lang.c so I won't elaborate.

    Jorgen Grahn, Feb 15, 2014
  7. I'm not familiar with Mythryl, so I don't know how it handles non-null pointer
    types. However I do know C++ - I've recently returned to it because I've
    started a new job, and we have to write plug-ins for a program implemented
    in C++, so I've no choice but to use it.
    One of the problems with references is that they have to be initialised very
    early. So in the case of our graph, when the graph is constructed the links
    can never be null (for the sake of argument). So there's a strong case for
    a non-nullable pointer. But that makes it difficult to construct the graph.
    Malcolm McLean, Feb 15, 2014
  8. Lynn McGuire

    Kaz Kylheku Guest

    I'm afraid you're mistaken.

    A C++ program which uses null references could could be verified to generate
    completely robust machine language that is impervious to bad inputs.

    gets is actually dangerous; whereas the above trick is only dangerous on paper.
    Kaz Kylheku, Feb 15, 2014
  9. Lynn McGuire

    Jorgen Grahn Guest

    Hm ...
    But that's also the /good/ thing about C++ references! Noone said
    they would replace pointers; it's just nice that you can use them to
    state your intentions more clearly in many (but not all) cases. For
    the other cases, you still have pointers.
    Jorgen Grahn, Feb 15, 2014
  10. Lynn McGuire

    Kaz Kylheku Guest

    And this property is still useful if you "abuse" references and bind
    them to null. Such a reference cannot be anything but that null over
    its entire lifetime (compared to a pointer, which could start non-null
    and be inadvertently set to null).
    Kaz Kylheku, Feb 16, 2014
  11. Lynn McGuire

    Kaz Kylheku Guest

    The author of this article identifies a problem, but doesn't understand
    its real cause. The root cause of the problem is the static type system with
    its typed references to objects.

    By this, I mean the idea that a value such as a string is
    actually manipulated by some "reference to string" pointer-like type
    (variables and parameters being statically of this reference type).

    Taking such a language as it is, and then disallowing those references from
    having a null value will only add to the pain.

    The fix is to get rid of these clumsy typed references. The referencing is
    hidden as part of the implementation of variable bindings (and other storage
    locations). All named and unnamed storage locations simply contain values.

    There can be a single value "nil" which is not equal to any other object.

    Then, say, passing nil to a string operation isn't a "null reference" problem;
    but an ordinary type mismatch, just like passing 123 or 3.0E+3 to a string
    function. It's just an object of the wrong type.

    Static type inference can catch instances of this problem in programs
    which are statically analyzable.

    Because it has its own type, you can route it to different methods: to make a
    one-argument function that accepts either nil or a string, just write two
    methods: one for the string class, and one for the class to which nil belongs
    (like the null class in Common Lisp).
    Kaz Kylheku, Feb 16, 2014
  12. Lynn McGuire

    Phil Carmody Guest

    This is OT, as it's C++, but wouldn't the compiler be able to
    just ignore this whole block, as it's impossible in the absence
    of UB, and ignorable in the presence of UB?
    Worse, I'd say.

    What Alice Hill, President at Slashdot Media, writes:
    Proven track record innovating and improving iconic websites
    (Slashdot.org, ...) while protecting their voice and brand integrity
    What Alice Hill means:
    2013: Completely fucked up Slashdot, and ignored almost endless
    negative feedback about her unwanted changes. 2014: Killed slashdot.
    Phil Carmody, Feb 16, 2014
  13. not according to the OO people. The NullClass is a recognised design pattern. The claim is it simplifies things!
    nick.keighley.zczc, Feb 18, 2014
  14. "technical debt" always raises my suspishions
    nick.keighley.zczc, Feb 18, 2014
  15. not if you read the quote on wikipedia he isn't
    nick.keighley.zczc, Feb 18, 2014
  16. dunno but people don't do it!
    nick.keighley.zczc, Feb 18, 2014
  17. One of the attributes of what I call a "safe language" is global error
    trapping - i.e., like in (most dialects of) BASIC, where any untrapped
    error causes a program abort. Then you don't need to check the return
    value of every function call (like you do in C).

    C is, thus, obviously not a "safe language". And never will be.

    Not that there is anything wrong with that...
    Kenny McCormack, Feb 18, 2014
  18. And one more comment on this - in the context of "what other languages do".

    One language that I use frequently is, by default, like (most dialects of)
    BASIC - that is, any (untrapped) error is fatal. But it has a command
    (ErrorMode(@OFF)) that makes it like C - where now you have to check every
    single function call.

    It is an ongoing perennial problem for the support staff that when
    beginners find out about ErrorMode, they use it in every program by
    default. Because they think that error messages make their programs

    With predictable results.

    The commonly heard slogan on the support board for this language is:

    Using ErrorMode(@OFF) turns a 5 minute debugging job into a 6 month one.

    There's a lesson in there regarding C somewhere...

    "If our country is going broke, let it be from
    feeding the poor and caring for the elderly.
    And not from pampering the rich and fighting
    wars for them."

    --Living Blue in a Red State--
    Kenny McCormack, Feb 18, 2014
  19. Lynn McGuire

    Les Cargill Guest

    This is why there is the "assert()" construct...
    Les Cargill, Feb 19, 2014
  20. It's a case of coding riund deficiencies in a language.
    If the language doesn't have a concept of "null", you can create it by adding
    an "isnull" flag to every object, then checking it in every member function.
    It's tedious, but it works.
    Malcolm McLean, Feb 19, 2014
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.