translate-c generates Zig code that does not compile.

[JesseRMeyer]

Consider:

typedef long HRESULT;
#define _HRESULT_TYPEDEF_(_sc) ((HRESULT)_sc)
#define DXGI_ERROR_NOT_FOUND _HRESULT_TYPEDEF_(0x887A0002L)

translate-c:

pub inline fn _HRESULT_TYPEDEF_(_sc: var) @TypeOf(if (@typeId(@TypeOf(_sc)) == .Pointer) @ptrCast(HRESULT, _sc) else if (@typeId(@TypeOf(_sc)) == .Int) @intToPtr(HRESULT, _sc) else @as(HRESULT, _sc)) {
    return if (@typeId(@TypeOf(_sc)) == .Pointer) @ptrCast(HRESULT, _sc) else if (@typeId(@TypeOf(_sc)) == .Int) @intToPtr(HRESULT, _sc) else @as(HRESULT, _sc);
}
const DXGI_ERROR_NOT_FOUND = _HRESULT_TYPEDEF_(@as(c_long, 0x887A0002));

However:

error: integer value 2289696770 cannot be coerced to type 'c_long'
pub const DXGI_ERROR_NOT_FOUND = _HRESULT_TYPEDEF_(@as(c_long, 0x887A0002));

Somewhat confusingly, in VS, the hex value mysteriously gets converted to UL:

I don't know if that is a function of the UI, and what the compiler ends up seeing.

What should translate-c do with C code that will not compile as Zig code?

[andrewrk]

Macros are translated on a heuristic basis. Not all macros can be translated.

This one looks like it can be, but it needs a more complicated Zig expression to express what the C code is doing.

[JustinRyanH]

@andrewrk is this a scenario where we need to identify when for signed integers and it's one bigger than maxInt in the pre_processor we translate it to minInt

[JesseRMeyer]

Macros are translated on a heuristic basis. Not all macros can be translated.

I'm not actually expecting for every macro can be translatable. I'm expecting that every translated macro be valid Zig.