Fix wild-pointer crash in RadarClass::Plot_Radar_Pixel on LP64 (radar/Comms Center)

[jazzyalex]

Problem

On 64-bit builds (arm64 macOS/iOS), placing a Communications Center (which enables the radar minimap) crashes with EXC_BAD_ACCESS on a wild pointer. Backtrace:

_platform_memmove
Mem_Copy
RadarClass::Plot_Radar_Pixel(short)
RadarClass::Draw_It(bool)
PowerClass::Draw_It -> SidebarClass::Draw_It -> ... -> Main_Loop

Root cause

In the zoomed-in radar path (ZoomFactor > 1), Plot_Radar_Pixel reads icon-set header offsets by hand:

long offset;
...
Mem_Copy(Add_Long_To_Pointer((void *)ptr, 28), &offset, sizeof(offset)); // "Map" offset
Mem_Copy(Add_Long_To_Pointer((void *)ptr, 12), &offset, sizeof(offset)); // "Icons" offset
ptr = Add_Long_To_Pointer((void *)ptr, offset + icon*(24*24));
Buffer_To_Page(0, 0, 24, 24, data, _TileStage);   // <- memmove crashes on wild ptr

The icon-set header stores 32-bit offsets — IControl_Type uses int32_t fields and is guarded by static_assert(sizeof(IControl_Type) == 32), with Icons at +12 and Map at +28. But offset is a long, and on LP64 sizeof(long) == 8, so each Mem_Copy reads 4 valid bytes plus 4 bytes of the following field. The result is a huge bogus offset → ptr + offset is a wild pointer → crash in Mem_Copy/Buffer_To_Page.

It only triggers when the radar is zoomed in (ZoomFactor > 1, i.e. smaller maps), which is why normal play is fine until the Comms Center turns the minimap on.

Fix

Read exactly 4 bytes by making offset an int32_t, matching the IControl_Type field type and the accessor-based paths (Get_Icon_Set_Map / Get_Icon_Set_Icondata) used elsewhere:

int32_t offset;

Verified by placing a Communications Center on a map that previously crashed on the arm64 macOS build.

🤖 Generated with Claude Code