Hacker News Reader

Comment by badmintonbaseba | Hacker News Reader

I just skimmed through the proposed wording in [N3322]. It looks like it silently fixes a defect too, NULL == NULL was also undefined up until C23. Hilarious.

[N3322] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3322.pdf

View on HN

This is probably related to the issue with NULL - NULL mentioned in the article.

Imagine you’re working in real mode on x86, in the compact or large memory model[1]. This means that a data pointer is basically struct{uint16_t off,seg;} encoding linear address (seg<<4)+off. This makes it annoying to have individual allocations (“objects”) >64K in size (because of the weird carries), so these models don’t allow that. (The huge model does, and it’s significantly slower.) Thus you legitimately have sizeof(size_t) == 2 but sizeof(uintptr_t) == 4 (hi Rust), and God help you if you compare or subtract pointers not within the same allocation. [Also, sizeof(void *) == 4 but sizeof(void (*)(void)) == 2 in the compact model, and the other way around in the medium model.]

Note the addressing scheme is non-bijective. The C standard is generally careful not to require the implementation to canonicalize pointers: if, say, char a[16] happens to be immediately followed by int b[8], an independently declared variable, it may well be that &a+16 (legal “one past” pointer) is {16,1} but &b is {0,2}, which refers to the exact same byte, but the compiler doesn’t have to do anything special because dereferencing &a+16 is UB (duh) and comparing (char *)(&a+16) with (char *)&b or subtracting one from the other is also UB (pointers to different objects).

The issue with NULL == NULL and also with NULL - NULL is that now the null pointer is required to be canonical, or these expressions must canonicalize their operands. I don’t know why you’d ever make an implementation that has non-canonical NULLs, but I guess the text prior to this change allowed such.

[1] https://devblogs.microsoft.com/oldnewthing/20200728-00/?p=10...

> now the null pointer is required to be canonical

Yikes! This particular oddity seems annoying but sort of harmless in x86 real mode, but not necessarily in protected mode. Imagine code that wants to load a pointer into a register: it loads the offset into an ordinary register and the selector portion into a segment register. It’s permissible to load the 0 (null) selector, but loading garbage will fault immediately. So, if you allow non canonical NULL, then knowing that a pointer is either valid or NULL does not allow you to hoist a segment load above a condition that might mean you never actually dereference the pointer.

(I have plenty of experience with low-level OS code in all kinds of nasty x86 modes but, thankfully, not so much experience writing ordinary C code targeting protected mode. It sometimes boggles my mind that anyone ever got decent performance with anything involving far data pointers. Segment loads are slow, and there are not a lot of segment registers to go around.)

In real mode assembly days, ES and sometimes DS were just another base register that you could use in a loop. Given the dearth of addressing modes it was quite nice to assume that large arrays started at xxxx0h and therefore that the offset part of the far pointer was zero.

If so, it's one that's been introduced at some point post C99 -- the C99 spec explicitly defines the behaviour of NULL == NULL. Section 6.5.9 para 6 says "Two pointers compare equal if and only if both are null pointers, both are pointers to the same object [etc etc]".

I don't imagine NULL is defined as "pointing to an object", so I don't expect that clause to apply.

You completely skipped over the first part: "Two pointers compare equal if and only if both are null pointers"

> You completely skipped over the first part: "Two pointers compare equal if and only if both are null pointers"

Maybe he elided it in an optimisation pass?

Can't get much more of a reading comprehension failure than that. Good thing I don't write compilers.

Happens to everyone, don't worry, especially when trying to focus on details, ironically...

NULL == NULL was already defined -- but NULL <= NULL wasn't :)

My mistake.

Cannot find any confirmation to your statement. Otoh "All null pointer values (of compatible typewithin the same address space) are already required to compare equal. " in the limked paper.

NULL is not single type in any conventional sense (and is actually tricky to define in a way that makes it usable in the way most programmers expect).

Thus:

  T1* a = NULL;
  T2* b = NULL
  a == b; /* may be undefined at present, depending on the nature of T1 & T2 */

"NULL" in fact is a macro, not a part of the language. null (zero pointer) is, and it is explicitly defined in standard, that comparison of two null pointers lead to equality. You example simply won't compile, it is not undefined; the pointers simply are of different type, period.

here what standard says:

"A pointer to void may be converted to or from a pointer to any object type.

Conversion of a null pointer to another pointer type yields a null pointer of that type. Any two null pointers shall compare equal."

therefore, convert any of them or both to void amd compare. you'll get equality.

Reply on news.ycombinator.com