3 ms·

When migrating 32bit apps to 64bit platforms, it's common to follow the recipe: 1. Try to recompile on 64bit without any changes 2. Realize the program does n

When migrating 32bit apps to 64bit platforms, it's common to follow the recipe: 1. Try to recompile on 64bit without any changes 2. Realize the program does not work because the types have different sizes now 3. Cast everything on sight to types that have same size as in 32bit. 4. Now the program "works" (as in, it compiled and maybe ran but you didn't test thoroughly) This address space restrictions ensures that if you happen to cast a pointer in this way it will not work, forcing the developer to review what he's doing.

CalChris 4y ago
This argument is similar to my enforcing 32b cleanliness. Really, that was an issue back in the 90s. But this enforcement happened with the x86_64 to ARMv8 migration, 64b to 64b. So I would like an explanation from Apple for why this now. What is their rationale?
- DHowett 4y ago
  The first iPhones were AArch32, and there was likely a sizable contingent of iOS software that was written to target the only existing bitness at the time :) The same reasons GP offered still apply there. The amount of software directly ported from x86_64 to AArch64 was probably minimal.
gruez 4y ago
>3. Cast everything on sight to types that have same size as in 32bit. Which is why on windows they defaulted to 32 bits for ints
- WalterBright 4y ago
  Except for 16 bit Windows!
WalterBright 4y ago
> 2. Realize the program does not work because the types have different sizes now Such an enormous amount of time in C/C++ programming is devoted to accounting for the size of an int, long, wchar_t, and long long being unreliable when porting. This is why D has int fixed at 32 bits, long fixed at 64 bits. It's amazing how the problems just melt away. Now, just remember to use size_t for everything used as an index, and you're good to go. (ptrdiff_t is almost never needed.)
- yardstick 4y ago
  Isn’t it similar in C with using uint16_t, uint32_t, etc? IMO it helps to write programs from the ground up that you know will need to be cross compiled.
  - WalterBright 4y ago
    Yes, you could use int32_t. But who wants to type that? People default to convenience, and that's int. Besides, the C Standard Library doesn't even use stdint.h. Now you've got unknown implicit integer conversions going on. It's just not a solution.

CalChris 4y ago

This argument is similar to my enforcing 32b cleanliness. Really, that was an issue back in the 90s. But this enforcement happened with the x86_64 to ARMv8 migration, 64b to 64b. So I would like an explanation from Apple for why this now. What is their rationale?

DHowett 4y ago
The first iPhones were AArch32, and there was likely a sizable contingent of iOS software that was written to target the only existing bitness at the time :) The same reasons GP offered still apply there. The amount of software directly ported from x86_64 to AArch64 was probably minimal.

gruez 4y ago

>3. Cast everything on sight to types that have same size as in 32bit. Which is why on windows they defaulted to 32 bits for ints

WalterBright 4y ago
Except for 16 bit Windows!

WalterBright 4y ago

> 2. Realize the program does not work because the types have different sizes now Such an enormous amount of time in C/C++ programming is devoted to accounting for the size of an int, long, wchar_t, and long long being unreliable when porting. This is why D has int fixed at 32 bits, long fixed at 64 bits. It's amazing how the problems just melt away. Now, just remember to use size_t for everything used as an index, and you're good to go. (ptrdiff_t is almost never needed.)

yardstick 4y ago
Isn’t it similar in C with using uint16_t, uint32_t, etc? IMO it helps to write programs from the ground up that you know will need to be cross compiled.
- WalterBright 4y ago
  Yes, you could use int32_t. But who wants to type that? People default to convenience, and that's int. Besides, the C Standard Library doesn't even use stdint.h. Now you've got unknown implicit integer conversions going on. It's just not a solution.