reinterpret_cast from hex literal to pointer

[cspace]

I have a hex literal to use as lpBaseAddress for the function below:

bool WINAPI WriteProcessMemory(
                        HANDLE hProcess, 
                        LPVOID  lpBaseAddress, 
                        LPCVOID lpBuffer,
                        SIZE_T  nSize,
                        SIZE_T  *lpNumberOfBytesWritten)

I plan to do the following, then pass p1 as lpBaseAddress to WriteProcessMemory:

#include <cstdint>
uintptr_t  v1{ 0x12345678 };
LPVOID     p1{ reinterpret_cast<LPVOID>(V1) };

My questions are:

(I'm sorry for the open ended questions below; if someone would like to answer, do feel free to address just one topic and forget the rest)

1) Does my code above confirm to ("modern/C++11/14") best practices?

(I think I've seen examples where v1 is stored as DWORD, then passed straight into WriteProcessMemory(); at other times I've seen (LPVOID) v1 used prior to calling the function: http://www.cplusplus.com/forum/beginner/9504/ )

2) Are such conversions above safe/predictable/have well defined behavior)?
I would be converting an integer to a pointer, does this fall under the "reverse round-trip" category below? (I don't think it does; at the same time, is there a reason and an example for "the same pointer may have multiple integer representations"?)

Below is the excerpt from: http://en.cppreference.com/w/cpp/language/reinterpret_cast :

A pointer converted to an integer of sufficient size and back to the same pointer type is guaranteed to have its original value...(the round-trip conversion in the opposite direction is not guaranteed; the same pointer may have multiple integer representations)

3) If an address has a 1 in its most significant bit (e.g., 0xFFFFFFFF), would the signed type INTPTR_T be inappropriate for storing the hex literal as address?
(my tentative answer is no, b/c it seems that both uINTPTR_T and INTPTR_T should work, since I could skip them both and instead do

LPVOID p1{ reinterpret_cast<LPVOID>(0x12345678)};

i.e., regardless of uINTPTR_T or INTPTR_T, they're the same bits underneath)

4) What exactly are the differences, in terms of internal implementation, between a pointer and an int initialized to 0x12345678?
(From http://www.cplusplus.com/doc/oldtutorial/variables/ , my tentative answer is that there's no difference in terms of internal implementation; the type information is only there to help the compiler interpret the bytes in memory)

Thank you very much

[dhayden]

4) What exactly are the differences, in terms of internal implementation, between a pointer and an int initialized to 0x12345678?

The short answer is that if your hardware uses a flat address space (and nearly all CPUs do now), then you don't have to worry.

The long answer is to consider the case of an 8086 processor with segmented memory. Memory access instructions specify a 16 bit address. To get the actual memory address, this 16 bit value is combined with a 16 bit segment register using (segmentRegister << 4) + address to get a 20 bit physical memory address.

Now consider the physical address 0x12345. This can be reached with seg=0x1234, addr=5, or with seg=0x1233, addr=0x15 or .... The point is that there are multiple ways to represent the same physical address. So there may be multiple ways to map an address to an integer. That's the reason for this round-trip stuff.

And if you're wondering why anyone in their right mind would create a computer like this, the answer is cost and backward compatibility. Sadly, IBM chose this processor for the PC in 1980 and software had to jump through extraordinary hoops for 15 years to get anything done. If they'd used the 32-bit 68000 instead, I really believe that we'd be 5-10 years ahead in consumer computing. Unfortunately, that probably would have meant waiting a few months to release the IBM PC.

[cspace]

Happy Thanksgiving :)

Thank you for clarifying the round-trip issue and pointer implementation; I couldn't find such information online, and rather ended up with lots of info on smart pointers and/or inheritance