Mill Computing, Inc. Forums The Mill Architecture NULL pointer

  • Author
    Posts
  • goldbug
    Participant
    Post count: 53
    #3091 |

    Hi Ivan

    let’s say I have a null pointer in my application:

    int * myPointer = NULL;

    Would that be compiled to a local pointer or global pointer? If it was a local pointer, then NULL would not be 0, because it would have the local bit set.

    I guess it would make sense to make NULL a special case and make it a global pointer? after all if you fork, a global NULL is still a global NULL, and having a value other than 0 for NULL would break a lot of applications.

    • This topic was modified 7 years ago by  goldbug.
  • Ivan Godard
    Keymaster
    Post count: 689

    It’s a global pointer. It has to be, because a local zero is an alias for the start of the turf’s private region.

    The language does not in fact require a NULL to be binary zero – the “0” in “p = 0” is a token, not a value. Thus “p = (void*)(x-x)” is not guaranteed to leave p NULL. However, nearly all modern machines do in fact use binary zero for NULL, and we do too.

    • Dave
      Participant
      Post count: 10

      Are there any advantages to not having NULL work out to be 0? I can’t think of any off the top of my head, and you’d lose the advantage (at least on a Mill) of having uninitialized pointers automatically being NULL.

      (As a hypothetical question, I mean… not as a direct response to Goldbug)

      • This reply was modified 7 years ago by  Dave.
      • Ivan Godard
        Keymaster
        Post count: 689

        The possibility is for legacy compatibility, for machines like the PDP-10 for which address zero had a hardware-defined meaning.Some future standard may deprecate it.

        The Mill reserves more than the zero address, to catch code like:

        struct S{int a; int b}; int* p = static_cast<struct S*>(NULL);
        ... //other code
        int i = *p;

        Of course app code won’t have permissions for ultra-low addresses, but system code may, and hardware poisoning the range helps catch bugs in privileged code. In addition, it lets the fault distinguish between (likely) null-pointer vs. wild address.

        We try to be friendly.

You must be logged in to reply to this topic.