Not a bug but instead relying on undefined behaviour.
NSLog(NSString *format, ...) is a variadic function but you've defined it as accepting merely two parameters with:
NSLog(format.i, message.i).
Because of calling convention differences between Apple's AMD64 and ARM64 platforms, we see the breakage here. It's only a coincidence that it works with AMD64 due to overlap between the typical convention and that used for variadic argument lists.
Potential solutions:
- Bump a feature request for variadic functions, so the language/compiler can accommodate these as needed.
- Has been requested a couple times: 1, 2.
- Would be nice to have, so more FFI cases can be covered.
- This would be much more work for @Fred, and require a permanent change to PB's syntax.
- Update the VCall module to handle ARM64 + C-backend.
As a workaround (not a true solution), you can pass sufficient arguments to manually satisfy expected layout:
Code: Select all
Macro CocoaAllocString(String)
CocoaMessage(0, 0, "NSString stringWithBytes:", @String, "length:", StringByteLength(String), "encoding:", #NSUTF16LittleEndianStringEncoding)
EndMacro
ImportC ""
NSLog(format, message)
EndImport
Define format = CocoaAllocString("Output: %S")
Define message.s = "Test: " + FormatDate("%HH:%II:%SS", Date())
CompilerIf #PB_Compiler_Processor = #PB_Processor_Arm64
CallFunctionFast(@NSLog(),
format,
0,
0,
0,
0,
0,
0,
0,
@message)
CompilerElse
NSLog(format, @message)
CompilerEndIf
Though, a simpler workaround would almost certainly be to disregard the variadic nature entirely, and compose the string to log on PB's end (taking care to replace any "%" with "%%").
