Peter,
Here are some more thoughts based on your answers.
> Yes, we are basically interested in the bit pattern.
For this to work in general for 64-bit pointers, you would have to be very careful to avoid any sort of floating point operations. On the C/C++ side you would have to do something like *(long long*)&variable when using it. On the TestStand side, you would need to avoid doing much of anything besides holding on to it. Even when comparing it you would have to be careful. Remember that there are multiple representations of some values, and then there is NaN. (Also, TestStand's handling of NaN is not IEEE compliant, complicating things even more.)
> yes, this is the original test case
Just to clarify: Are you seeing the example (test_small_number.seq) attached to this thread failing? Or is this some other (private) test case?
> We have not used TestStand 2014 in 32-bit at all, so I cannot say.
Depending on exactly what you are doing, this could make a difference. In 32-bit TestStand 2014 and ealier, SSE2 is disabled for certain operations to maintain backward compatibility with behavior prior to the existence of SSE2. SSE2 cannot be disabled in x64 applications. This means that there will be differences between 32-bit TestStand 2014 and 64-bit TestStand 2014 for some floating point operations. (TestStand 2014 was the first release with 64-bit support.) In 32-bit TestStand 2016, we no longer disable SSE2. This means that there are subtle differences in floating point behavior between 32-bit TestStand 2016 and earlier versions of 32-bit TestStand, but 32-bit TestStand 2016 and 64-bit TestStand 2016 agree with each other.
Taking into account all of the above, one plausible scenario is that you have top-down addressing turned on on the system where your test does not work. The top-down addressing registry key tells Windows to start at the top of the heap, allocating big addresses first and moving down. 64-bit applications that seemed to work fine before often crash almost immediately with this option.
The default heap allocator in Windows allocates memory starting at low numbers and moving up. These numbers will have all zeros for their high-order bits. This is one reason why people often fail to find bugs when adding 64-bit support to existing systems. It is very possible to miss a place where the high order bits of a pointer are truncated, but still have your program work. In fact, your program will likely work most of the time, right up until the point the heap grows larger than 4GB, where the high bits suddenly start mattering and your program goes down in flames.
Something similar could be happening with your system, albeit with respect to the behavior of floating point numbers vs. simple integer truncation. For example, if you are ever copying the addresses from your pointers to a TestStand number (or double) without first taking the address and doing a pointer cast, pointers with small integer values will work correctly, but large pointers will be rounded. Alternatively, it may be that you are copying the bits correctly everywhere, but turning on top-down addressing turns the associated doubles into NaNs. When doing IEEE compliant calculations, NaN is not equal to itself. (However, TestStand itself is not IEEE compliant, and all NaNs are all generally equal to each other, which makes this whole question even messier.) Either way, this is a recipe for problems.
