Some notes:

x86 ffunn

It was actually more complicated than “zero is null is the IVT,” because three pointer types were possible to objects or functions (__near, __far, or __huge), and these would default differently depending on your memory model, and from the ’286 on, the number of architectural-nulls actually depended on the setting of the A20EN line and IDTR and the CPU mode.

__far pointers are what you’re probably thinking of—all-zeroes gave you address zero, which is where the IVT started (’286+: by default). But pre-’286 or with A20EN disabled, you could also hit that address with FFFF:0010, FFFE:0020, FFFD:0030, etc. because the segment (←) and offset (→) were combined as 16×seg+off, and C wouldn’t generally see the high addresses as null even though they aliased. With A20EN enabled (’286+), FFFF:0010 and up were de-aliased, which let you (or rather, DOS) use the 65520 B of RAM that started at the 1-MiB mark, called the High Memory Area (HMA).

__huge pointers were a normalized form of __far, which generally kept bits 4 through 15 zero-valued, so you only had 16 offsets per segment. All-zeroes was still null in both C and hardware, but you couldn’t reach the HMA. However, if you tweaked the bytes of the pointer directly, you could potentially encode sometime-nulls by keeping segment and bits 0–3 of offset =0, but setting bits in the 4–15 region. It was effectively undefined whether C or underpinnings would see those as null or not—if tested/accessed after re-/normalization, then yes, else no. Similarly, with segment FFFF and nonnormal huge pointers, you might hit HMA or address zero (or not), but C would never see null unless it normalized unexpectedly, and then its idea of null and the hardware’s might differ.

For __near pointers, you had an implied segment that used whatever was in CS/DS/SS already, and the pointer only represented the offset, limiting you to 64KiB total for code and/or data. Thus, unless you’d frobbed a seg reg, which took a bit of effort or a bug elsewhere, or perhaps running byte 0F on an 808x (which used that for POP CS, not extended opcodes as on ’286+), you wouldn’t generally be in segment 0 contextually, and offset zero would be local to your code and/or data segment.

However, there was potentially an important structure there, placed by DOS: Your 512-byte program segment prefix (PSP). That included information about your program and its command line, so frobbing it could have wide-ranging effects. This was especially an issue for the Tiny model used by .COM files and upconverted 8080/8085 code, where code, data, heap, and stack all had to fit into 64 KiB-512 B unless you did up your own far gunk to escape. Address zero must always be CD 20, which codes a DOS exit syscall (INT 20h), because that was how you ended an 8080/8085 program, jmp/call 0. Very few DOS programs actually exited that way, fortunately, and the exit function usually used an INT 21h syscall that accepted an exit status.

I mentioned IDTR, which was added with the ’286. It was primarily intended for protected mode, but you could relocate the real-mode IVT to an arbitrary address with it—though you wouldn’t, generally, unless you were intercepting interrupts separately.

In protected mode and the i432 ISA its guttiwuts derived from, both GDT and LDT carried an unused null entry, and any offset into that would trigger a fault. Segments were now coded as selectors carrying a table select bit and two RPL bits, so there were 8×65536 possible null pointer codings. But you still had near/far and hypothetically huge pointers, so near nulls were just offset 0 in a valid segment.

Aperture size

The null aperture in flat address spaces (=most, or via x86 near) has a particular size. That means that accidental access to a large non-object (us. an array) via a null pointer can accidentally escape the null aperture and access valid memory! E.g.,

int *big = malloc(16777216L);
// Assume malloc fails, and big == NULL. Then
big[1048576] = 0;
// might succeed, if the aperture is ≤4 MiB in size, and assuming 4-B int.

On Linux IA32, you generally have read-only memory starting at the 4-MiB mark IIRC, then after .text and .rodata come writable .data and .bss.

In x86 real mode, the BIOS data area (BDA) followed the IVT, so frobbing things there would break things that used BIOS or DOS (which used BIOS) services. After the BDA, there might be some DOS data, then possibly the ’286 LOADALL area, then more DOS data, so null with a larger offset could be quite dangerous.

Integer-pointer casts

Pretty much any cast between integer and pointer should be viewed as suspect in portable codebases, with or without involving uintptr_t—and that requires C≥99 or C++≥11 support (or most C9x or C++0x approximations thereunto), and that type is optional in the first place—e.g., OS/400 ILE in P128 model has none, for example, and it will only round-trip like 24 bits of a pointer via cast to/from int, unsigned, long, or unsigned long.

You mentioned these casts are ISB, and there’s enough variation in behaviors that it’s a far better idea not to rely on it at all.

The last real necessary uses for it are

• implementing memmove,

• implementing an allocator, or

• detecting object/pointer alignment absolutely.

Of these, the first two necessarily involve some ABI/OS/ISA assumptions, and the final doesn’t make sense in the pure Abstract Machine models, where objects and functions might be positionless islands unto themselves.

It does make sense to assume some minimal necessary alignment of a base pointer, and then find the alignment of (char *)relptr - (char *)base instead (which assumes both pointers are to the same underlying object).

C23 does give us an absolute memalignment function in both freestanding and hosted impls, so presumably you’d have to know segment base alignments a priori to implement that in 16-bit protected mode, or just limit your maximal considered alignment to 16 bytes (a.k.a. one “paragraph”) or so, which was the allocation granularity of both the DOS and OS/2 kernels.