5 ms·

> Maybe to get more compact data structures? Even if this is why, there is never a valid excuse for blindly truncating 64-bit pointer to 32-bits. It's just lik

> Maybe to get more compact data structures? Even if this is why, there is never a valid excuse for blindly truncating 64-bit pointer to 32-bits. It's just like saying "I'm gonna just go ahead and truncate all bank account balances to 16-bit integers to save memory in my data structures." It may be the reason, but that reason is still incredibly stupid.

cnvogel 11y ago
> It may be the reason, but that reason is > still incredibly stupid. Sometimes there are stupid reasons, but sometimes even reasons which are incredibly stupid from a technical standpoint make sense in a broader context. For a short-term fix, for example, I can very well imagine to prefer this "trick" forcing sub-4G allocations if the other alternative would be to change 1000 places in undocumented legacy code doing crazy casts... And if it's for a product (or product component) on life-support only needed for a forseeable future, to me it makes perfect sense to ask the initial "crazy" question, even if it makes me cringe...
- sjolsen 11y ago
  I'd suggest that even if it's absolutely necessary, one could at least put something like #if (ULONG_MAX < UINTPTR_MAX) && !defined (SUPPRESS_TRUNCATION_ERROR) #error Truncating pointers to long is a bad idea here #endif in some source file or another, just so you have some indication whether or not things are going to break when you change the build environment.
  - cpeterso 11y ago
    static_assert(sizeof(DWORD) == sizeof(void*), "assume 32-bit pointers");
    - sjolsen 11y ago
      If we're talking about "undocumented legacy code doing crazy casts," static_assert is probably not an option.
- cpeterso 11y ago
  Perhaps the maintainer of the legacy application can override operator new to use a custom memory allocator that uses a block of memory allocated below 4GB using VirtualAlloc.
- xg15 11y ago
  > For a short-term fix, for example, I can very well imagine to prefer this "trick" forcing sub-4G allocations ... But that's not what this is doing - it's taking an address allocated at an arbitrary place and then pretends that it was allocated sub-4G, whether or not it actually was. If it happens that it wasn't, this will likely cause memory corruption or an access violation. Even if your product is nearing end-of-life, I'd still consider such a move a big "f* you" to your customers as you'd basically be tolerating that your product may crash without warning at any time. From what I understood, what makes this idea so bad isn't truncating to 32bit - it's truncating to 32 bit while setting the LARGEADDRESSAWARE build flag - which basically tells the OS "I'm fine with all kinds of 64bit addresses, bring them on!" The correct fix is outlined at the end of the article - and it does not involve combing through undocumented legacy code: > If there is some fundamental reason that they have to truncate pointers to 32-bit values, then they should build without /LARGEADDRESSAWARE so that the process will be given an address space of only 2GB, and then they can truncate their pointers all they want.

cnvogel 11y ago

> It may be the reason, but that reason is > still incredibly stupid. Sometimes there are stupid reasons, but sometimes even reasons which are incredibly stupid from a technical standpoint make sense in a broader context. For a short-term fix, for example, I can very well imagine to prefer this "trick" forcing sub-4G allocations if the other alternative would be to change 1000 places in undocumented legacy code doing crazy casts... And if it's for a product (or product component) on life-support only needed for a forseeable future, to me it makes perfect sense to ask the initial "crazy" question, even if it makes me cringe...

sjolsen 11y ago
I'd suggest that even if it's absolutely necessary, one could at least put something like #if (ULONG_MAX < UINTPTR_MAX) && !defined (SUPPRESS_TRUNCATION_ERROR) #error Truncating pointers to long is a bad idea here #endif in some source file or another, just so you have some indication whether or not things are going to break when you change the build environment.
- cpeterso 11y ago
  static_assert(sizeof(DWORD) == sizeof(void*), "assume 32-bit pointers");
  - sjolsen 11y ago
    If we're talking about "undocumented legacy code doing crazy casts," static_assert is probably not an option.
cpeterso 11y ago
Perhaps the maintainer of the legacy application can override operator new to use a custom memory allocator that uses a block of memory allocated below 4GB using VirtualAlloc.
xg15 11y ago
> For a short-term fix, for example, I can very well imagine to prefer this "trick" forcing sub-4G allocations ... But that's not what this is doing - it's taking an address allocated at an arbitrary place and then pretends that it was allocated sub-4G, whether or not it actually was. If it happens that it wasn't, this will likely cause memory corruption or an access violation. Even if your product is nearing end-of-life, I'd still consider such a move a big "f* you" to your customers as you'd basically be tolerating that your product may crash without warning at any time. From what I understood, what makes this idea so bad isn't truncating to 32bit - it's truncating to 32 bit while setting the LARGEADDRESSAWARE build flag - which basically tells the OS "I'm fine with all kinds of 64bit addresses, bring them on!" The correct fix is outlined at the end of the article - and it does not involve combing through undocumented legacy code: > If there is some fundamental reason that they have to truncate pointers to 32-bit values, then they should build without /LARGEADDRESSAWARE so that the process will be given an address space of only 2GB, and then they can truncate their pointers all they want.