fix(mac): correct memory width mismatch in keyCodeForChar

[PekingSpades]

(@darcywong00 edited to skip user testing)

Summary

Fix a memory corruption bug in keyCodeForChar() function in mac/TestInput/TestInput/TestInputController.m where a 64-bit pointer-sized value was being written into a 16-bit CGKeyCode variable, causing stack corruption.

Problem

The original code had a dangerous pointer/memory width mismatch:

CGKeyCode code;  // uint16_t, 16 bits
// ...
CFDictionaryGetValueIfPresent(charToCodeDict, charStr, (const void **)&code)

CFDictionaryGetValueIfPresent writes a pointer-sized value (64 bits on modern systems) to the memory location provided. Casting &code (a pointer to a 16-bit variable) to const void ** causes the function to write 8 bytes into a 2-byte memory location, corrupting 6 bytes of adjacent stack memory.

This is undefined behavior and can lead to:

• Stack corruption
• Random crashes
• Incorrect return values

Solution

Use an intermediate pointer-sized variable to safely receive the dictionary value, then cast to CGKeyCode:

const void *value = NULL;
CGKeyCode code;
if (CFDictionaryGetValueIfPresent(charToCodeDict, charStr, &value)) {
    code = (CGKeyCode)(uintptr_t)value;
} else {
    code = UINT16_MAX;
}

References

Apple Documentation

• CFDictionaryGetValueIfPresent | Apple Developer Documentation
• Apple CF Source - CFDictionary.h - The value parameter is documented as: "A pointer to memory which should be filled with the pointer-sized value if a matching key is found."

64-bit Porting Best Practices

• 20 issues of porting C++ code to the 64-bit platform (PVS-Studio) - Documents similar pointer truncation bugs: "Both examples do not take into account that the pointer size may differ from 32-bits. They use explicit type conversion which truncates high bits in the pointer, and this is an error on the 64-bit system."

may related issues: #3084 #894 #1005 #1072 #1143 #11674 #11673 #11057

Test-bot: skip

[keymanapp-test-bot]

User Test Results

Test specification and instructions

User tests are not required

[keyman-server]

This pull request is from an external repo and will not automatically be built. The build must still be passed before it can be merged. Ask one of the team members to make a manual build of this PR.

[mcdurdin]

Thank you for your PR @PekingSpades. I am curious, what is your purpose in submitting this PR?

This is in an internal app that does not get distributed, and is used for test purposes only. Clearly you have found a bug (and it appears, using AI to generate the PR?), but it is of low significance and zero impact to end users, so your PR does not provide a lot of benefit.

[PekingSpades]

Hi @mcdurdin

Thanks for the feedback. I’d like to clarify that I am a human developer, not a bot. To be honest, I have no incentive to waste my own computing power or rack up expensive token bills just to blindly scan repositories for low-impact bugs—especially since current AI models aren't actually capable of detecting this specific logic flaw on their own. I discovered this issue manually while working deeply with robotgo and realized that this same error has been propagated across several major GUI automation libraries, like nut.js, through various forks and ports over the years.

While I did use AI to help draft the PR description for better clarity, the discovery and the fix itself came from my own investigation. My motivation for submitting this is quite simple: I currently work at an AI company focusing on model training, so I am acutely aware of how critical high-quality, "clean" code is for the future of development. I submitted this PR because I respect your work and don't want AI models to learn from and further spread incorrect code patterns. I believe keeping our open-source ecosystem's "source material" clean benefits everyone, regardless of whether the tool is for internal testing or production.

Best regards,
@PekingSpades

[mcdurdin]

Thanks @PekingSpades for your thoughtful reply -- understand and agree that good clean code across the open source ecosystem is pretty important for the future (but perhaps an insurmountable challenge?). I will let @sgschantz review this as it is his area, but from my perspective, this does look like a good cleanup.

[sgschantz]

lgtm

[mcdurdin]

Looks like the original version of this code is from https://stackoverflow.com/a/1971027/1836776. I have submitted an edit for the answer.

[keyman-server]

Changes in this pull request will be available for download in Keyman version 19.0.188-alpha