Home > Back-end >  Full emulation of `intptr_t` with `ptrdiff_t` and `nullptr`?
Full emulation of `intptr_t` with `ptrdiff_t` and `nullptr`?

Time:02-23

Given that intptr_t is optional and ptrdiff_t is mandatory, would p - nullptr be a good substitute for (intptr_t)p, to be converted back from a result denoted by n with nullptr n instead of (decltype(p))n? It's IIUC semantically equivalent on implementations with intptr_t defined, but also works as intended otherwise.

If I'm right in the above, why does the standard allow not implementing intptr_t? It seems the liberty thus afforded isn't particularly valuable, just a set of two simple local source code transforms (or an optimized equivalent) to shave off.

CodePudding user response:

No. ptrdiff_t only needs to be large enough to encompass a single object, not the entire memory space. And (char*)p - (char*)nullptr causes undefined behavior if p is not itself a null pointer.

p - nullptr without the casts is ill-formed.

  • Related