Hacker News Reader

Comment by notacoward | Hacker News Reader

The problem comes from the assumption that NULL is the same as zero. Even the author makes that assumption, when he gives an example that explicitly uses zero and then talks about it as if it had used NULL. In fact, the two have never been the same. I've worked on machines that represented NULL with a different value/bitpattern, and yes, it smoked out a lot of these bad assumptions. NULL can never point to valid memory, by language definition. An explicit zero can, from a language standpoint, even if the runtime/OS might disagree. ;) Thus, uses like that in offsetof are quite valid.

View on HN

No, the problem comes from the assumption that you can legally fetch the "address" of a structure member via pointer dereference without checking for null so long as you don't actually try to access the resulting address.

    struct usb_line6 *line6 = &podhd->line6;

The assumption is that this is OK so long as you don't try to access the contents of line6 without doing some upstream null checking first. This assumption is false. The very act of dereferencing is undefined, regardless of whether you access the resulting address or not.

The assumption fails whether null is implemented as 0, 200, 0x8000000000000000, 0xffffffffffffffff.

There was no actual dereferencing, this is just pointer arithmetic. it's "line6 = podhd + offset". There isn't really a better way to do it.

Most underlying implementations won't actually dereference here (which is why it usually works), but as far as the spec is concerned, you are dereferencing it, which is undefined.

That becomes a problem with modern optimizing compilers, because they make assumptions about your code based on what's allowed according to the spec.

There is no pointer arithmetic in the line:

    struct usb_line6 *line6 = &podhd->line6;

Offset is calculated "below the hood". Pointer arithmetic is defined with arithmetic operands: +,-

-> and . are not arithmetic operands.

You sound very sure of yourself.

If you look at the definition of the -> and [], you might learn something!

Clearly, you don't have anything constructive to say, so you have to resort to ad hominem.

[] operator doesn't have any place in this debate.

Well, as far as I understand it, `->` works in a similar fashion to `[]`; the difference being that one behaves on arrays while the other on structs.

What @jwatte tried to say is that `->` works like this:

    // foo is struct thingity*
    &foo->bar == foo + offsetof(struct thingity, bar);

The `[]` does a similar thing:

    // s is char*
    *(s+i) == s[i]

Sure, &foo->bar looks like foo + offsetof(struct thingity, bar), but there is no pointer arithmetic involved since C doesn't specify how the member access ( -> or . ) is actually calculated.

It does however specify that [] operator is equivalent to pointer arithmetic. But we are talking ->,. operators and not [].

But NULL must, broadly speaking, be the same as zero.

C standard 3.2.2.3: "An integral constant expression with the value 0, or such an expression cast to type void * , is called a null pointer constant."

C standard 4.1.5: "The macros are... NULL, which expands to an implementation-defined null pointer constant."

See [1] for more info.

[1]: http://stackoverflow.com/questions/2599207/can-a-conforming-...

The constant 0 has to convert to NULL, but nonconstant zeroes don't, and NULL doesn't have to be 0 when converted back to an integer. This would break code like the example offsetof implementation.

NULL must compare equal to 0. That doesn't mean that it is represented by all 0 bits. NULL can have a value of anything add long as NULL == 0 is true.

Casting zero to a pointer yields a null pointer. That doesn't preclude other-valued null pointers, or ensure that a cast the other way will yield zero. That's where the "undefined" part comes from.

Casting a constant zero to a pointer type yields a null pointer. The conversion is done at compile time, so the compiler knows that a null pointer is the required result.

There is no requirement for an integer-to-pointer conversion to retain the bit pattern of the integer value, any more than an integer-to-floating-point conversion is required to do so.

In most modern implementations, conversions among integer and pointer types of the same size are trivial, simply reinterpreting the bits as a value of a different type.

A conforming C or C++ compiler can use, for example, the bit pattern 0xFFFFFFFF to represent a null pointer. Converting a constant 0 to a pointer type would yield a pointer with the representation 0xFFFFFFFF. Converting a non-constant 0 to a pointer type does not necessarily yield a null pointer; the result is implementation-defined, and may be indeterminate garbage.

The way I like to think about it is that integer zero is the name in the C/C++ language (and runtime) for the actual null pointer, nothing more or less. In particular you can't assume anything about the integer representation of the actual null pointer.

Reply on news.ycombinator.com