This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(12.8, 42%, 11%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EZN%3C/text%3E%3C/svg%3E)
My English is not perfect.
Visual C++ 2019 16.9.2.
I announced an error a long time ago, I do not find this. MS wrote will be fixed in a later version. But remained:
#include <iostream>
using namespace std;
int x = 1, y = 2;
int * __ptr32 (a[2]) = {&x, &y};
void f(int const &z) { wcout << &z << endl; }
int wmain() {
f(*(a[0]));
int &z = *(a[0]);
int *p = a[0];
wcout << &z << endl << p << endl << &y << endl;
return 0;
}
In a 64 bit program, when a 32 bit pointer is passed to a function, as the address of a reference parameter, reads 64 bit from memory. So, the address will be bad. The program crashes if there is z instead of &z in wcout in the function f. This program requires disabled LARGE_ADDRESS_AWARE among linker's settings. This causes the program can use only 2 GB address space: 0 to 2^31-1 addresses. Debug and Release mode are concerned so. AMD64 is concerned, I have no information about ARM64.
32 bit pointers in 64 bit program useful if the program uses a lot of pointers: lists, trees, etc. This can halve memory need. 64 bit mode required to processor test/benchmark program, what must use 64 bit dlls. In 64 bit mode, there are 16 registers instead of 8, so faster. Memory comb, fill, copy, exchange, compare, arithmetic operations on big numbers has double speed than 32 bit mode.
On a 32-bit system, a pointer declared with __ptr64 is truncated to a 32-bit pointer.
On a 64-bit system, a pointer declared with __ptr32 is coerced to a 64-bit pointer.
https://learn.microsoft.com/en-us/cpp/cpp/ptr32-ptr64?view=msvc-160
I don't any issue here, the documentation is clear enough that __ptr32 (32 bit pointer) will be 64 bit pointer in x64 application.
32 bit pointers in 64 bit program useful if the program uses a lot of pointers: lists, trees, etc. This can halve memory need
You may gain some memory but very far from halve the memory used, and not for free, there will be performance overhead.
This is an error. In f, write to the display the value of the parameter, not the address. The program will crash. Naturally, pointers are 64 bits. If 32 bit is stored, must be zero- or sign-extended, does not extended by the next 4 bytes in the memory!
If the data structure mainly consists pointers and counters, the memory usage will be near halved. Using 32 bit pointers in 64 bit mode does not slower than in 32 bit mode, and does not slower than using 64 bit pointers. The AMD64 architecture guarantes this, ARM64 so.
Could you please tell us where did you post the issue a long time ago? Is it on DC? Could you please provide the link and then we can help you to push the thread.
This is an error. In f, write to the display the value of the parameter, not the address. The program will crash.
First, please note that int x data type is 4 bytes here that is 32 bits, and since __ptr32 coerced to 64 bit pointer what you're trying to do is read 64 bits out of 32 bit value.
Secondly, this could be an error in case of dynamic storage, but variable int x from your example is allocated on the stack!
And as you know, reading stack variable out of it's assigned storage is not valid.
I do not remember: developercommunity, technet, or other. I did not find. The title was about:
32 bit pointers in 64 bit program: reads 64 bit from memory
There was disassembly so in the error report.
x, y, a are global variables, not on the stack!
The error happen only at f. After the call, at z, p are correct.
#include <iostream>
int a[2] = {0, 1};
f(__intt64 &z) { std::wcout << z << L'\n'; }
void wmain() {
f(a[0]);
return 0;
}
If you see 4294967296, the compiler is bad. The compiler does this with pointers.
You're correct, these variables are not on the stack but global, but this doesn't change my point:
The code segment in memory is typically read-only and has a fixed size
https://en.wikipedia.org/wiki/Code_segment
And my point was that you implicitly attempted to read outside of allocates storage, because 32 bits were allocated, but since __ptr32 coerced into 64 bit pointer you're reading invalid memory.
The compiler isn't wrong here.
Your second example is as well ill formed because you again read 64 bits out of 32 bit fixed size storage.
You did not understand. The compiler is bad.
At example of int, I forget const: void f(__in64 const &z). Another example: f(__int64 z). This must write 0 to the display. If writes 4294967296, the compiler is bad. The compiler does exactly this with pointers.
I found this!