Structure alignment would align any int to the pointer, so same space in any case. Two CPU registers.
Perhaps, but the difference between value bits and padding bits is significant, and it seems pointless (and prone to compiler warnings about losing significant bits if you then try to assign the value back to its "real" type) to misrepresent its size.
Ah, I have a cunning piece of code to handle that. The problem was if the original source was say a char padded by the compiler to an intptr_t, and you erase that into an intptr_t. Seven bytes are therefore being accessed as UB, and random data could appear in there. Both of which are unhelpful. So I have a bit of trampoline code which constexpr initialises a union of the source type and the intptr_t which is initialised to all bits zero. We then set the source type, and read back the intptr_t. This ensures that the padding bits are all bits zero in the type erased form.
In private discussions with some on WG21, it is felt that status code needs to always be two CPU registers exactly. So I'll be bumping that to intptr_t on all platforms.
Why? What benefit does this provide?
So the compiler could be given a hard guarantee that an `error` can always be trivially returned. On x64 Itanium ABI, RAX+RDX is used to return a 16 byte value. The MSVC ABI currently does not use that mechanism on x64, it can only return up to 8 bytes trivially. A function potentially returning `error` would be mangled to say that it does so. The compiler therefore knows that one of the CPU flags (e.g. DF or SF) means whether to interpret RAX+RDX as an `error` or as an ordinary non-failure return value. That's why it's important that `error` fit into two CPU registers. `error` is now ready incidentally. https://ned14.github.io/status-code/doc_error.html. It's looking very promising. Be aware that https://wg21.link/P0709 currently results in a 404. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/