Open LaXiS96 opened 1 year ago
Is there any workaround to this issue? Can I override the C header declaration in my Zig code, somehow ignoring the translation error?
Also I have no idea what the actual cause is, is the volatile
keyword not supported by the translation backend?
Is there any workaround to this issue?
You can manually translate the macro that is causing the issue:
#define MMIO32(addr) (*(volatile uint32_t *)(addr))
#define SCS_DEMCR MMIO32(SCS_BASE + 0xDFC)
const SCS_DEMCR_ptr: *volatile uint32_t = @ptrFromInt(SCS_BASE + 0xDFC);
// replace uses of SCS_DEMCR with
SCS_DEMCR_ptr.*
Also I have no idea what the actual cause is, is the
volatile
keyword not supported by the translation backend?
parseCTypeName
does not support volatile
and const
qualifiers and even if it did it would also need to detect that that macro is supposed to be expanded into the function body and convert it into an inline function.
It's not exactly an easy fix which is why I put it in that milestone.
Thank you @Vexu, that workaround works as expected! I guess this just proves the point that preprocessor macros were never a great idea :)
Zig Version
0.12.0-dev.1342+13c7aa5fe
Steps to Reproduce and Observed Behavior
Trying to
@cImport
https://github.com/libopencm3/libopencm3Compilation result:
Line 69 of
libopencm3/cm3/common.h
:Expected Behavior
Import of C header to not fail