Hacker News Reader

Comment by scott_s | Hacker News Reader

Null is not a valid pointer, though. It's a valid pointer value, but it's undefined to dereference such a pointer. If the purpose of malloc is to return an address to usable memory, then null it outside of that range. Values outside of the legal range of a function are fine for error conditions. Because of that, null seems like a reasonable return value for error on malloc: I could not allocate memory for you, which I indicate by returning an address that you are not supposed to dereference.

However, I do agree it would be better if there was some other kind of error condition, preferably something like the option type from various other languages, or just an easy way to return multiple values like in Go. But C is not that language.

View on HN

> Null is not a valid pointer, though.

There are embedded systems out there (that have C compilers) that have addresses at 0 actually. 8051 C programmers know what I'm talking about.

IIRC, 0 is totally an address when inside the Linux kernel as well. What else do you call the first block of memory on a system?

Just because in userland the Linux Kernel pages memory to a very high-numbered region does not mean that under all circumstances "0" is an invalid address. The entire concept of "null == 0 == invalid" is an innate falsehood, an abstraction brought about by the malloc function (that a lot of other libraries have decided to copy).

But really, what do YOU call the first physical byte of RAM? Most systems I know of... from 8051 all the way to even Linux Kernel... calls it 0.

Nobody says that NULL has to be 0. C's NULL is just a pointer value that can be compared for equality but can not be used for pointer arithmetic or be dereferenced. Implementations commonly reserve some address (often 0) to represent that pointer value, as that is just the most efficient way to do it (rather than making pointers larger than the normal word size to be able to represent the sentinel value)--also, object sizes are limited to one less than the number of possible addresses anyway, simply because you can have objects that are 0-sized.

From the point of view of C, it seems that NULL is indeed always defined as 0. At least according to the C FAQ:

http://c-faq.com/null/machnon0.html

It might be that the internal representation used by the compiler is different, but from C a NULL pointer will always be equal to 0. See also:

http://c-faq.com/null/ptrtest.html

Well, yes, but from the view of C, pointer values are arbitrary anyway. There is no guarantee that a particular pointer's value has any particular relationship to which RAM cell of your hardware you are accessing.

You're confusing a "null constant" and a null pointer. An integral 0 being converted to a pointer at runtime is not required to be a null pointer, only an integral 0 converted at compile time is.

Dereferencing null is undefined behavior in a C program - which is another way of saying it is considered an error, and there are no guarantees about what will happen as a result of it.

From the standard (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf), "If an invalid value has been assigned to the pointer, the behavior of the unary * operator is undefined." In a footnote, it goes on to define what invalid values are. "Among the invalid values for dereferencing a pointer by the unary * operator are a null pointer, an address inappropriately aligned for the type of object pointed to, and the address of an object after the end of its lifetime."

And null is indeed defined to be 0. Also from the standard: "An integer constant expression with the value 0, or such an expression cast to type void *, is called a null pointer constant. If a null pointer constant is converted to a pointer type, the resulting pointer, called a null pointer, is guaranteed to compare unequal to a pointer to any object or function."

> Dereferencing null is undefined behavior in a C program - which is another way of saying it is considered an error, and there are no guarantees about what will happen as a result of it.

Indeed. It is undefined within C. It is an abstraction that C builds on top of. Dereferencing 0 on the vast majority of embedded systems (or kernel-level code) is very well defined.

This is just one of the areas where C has a "leaky abstraction".

It's an abstraction taken from C++ (and virally transmitted back to C99). ANSI NULL can be anything the implementer wants it to be, not just (void *)0.

Frankly it's the dumbest misfeature from C++ that should have had nullptr from day one. What's the point of constructing a rigorous type safety system if you're going to go and break it with magic integers that can act like pointers.

C can return a struct from a function. That's multiple return values.

Yeah, but it's cumbersome because you have to define that struct elsewhere, and C does not have elegant mechanisms for destructing in-place.

How about

  #include <stdio.h>

  typedef struct mystruct {
    int x;
    char *p;
  } mystruct;

  mystruct func(int n) {
    return (mystruct) { n, NULL };
  }

  int main(void) {
    mystruct v = func(1);
    printf("%d\n", v.x);
    printf("%d\n", func(2).x);
    return 0;
  }

Works fine with gcc 5.3.1. Multiple destructuring is (maybe) problematic, but if you really want this.

That has both downsides I mentioned.

Reply on news.ycombinator.com