C interop: expected type `bool` found `c_int` about zig HOT 6 OPEN

More minimal foo.h:

#define bool _Bool
#define true 1
#define false 0

The last 3 lines of zig translate-c foo.h:

pub const @"bool" = bool;
pub const @"true" = @as(c_int, 1);
pub const @"false" = @as(c_int, 0);

from zig.

I have a pretty janky workaround:

@cImport({
    @cDefine("true", "(_Bool)1");
    @cDefine("false", "(_Bool)0");
    @cInclude("stdbool.h");
    @cUndef("true");
    @cUndef("false");
    @cDefine("true", "(_Bool)1");
    @cDefine("false", "(_Bool)0");
    
    // other @cInclude()s that use stdbool.h...
});

A couple of points of explanation:

1. We must use (_Bool)1, not (bool)1. The latter confuses zig and it just doesn't understand what the 1 is doing there
2. We must pre-define as well as post-define true and false. If we only define it before, stdbool.h will override, and if we only define it after, zig will use the first definition (from stdbool.h) to generate its own idea of what true and false are.
3. We could also just replicate stdbool.h but with altered definitions of true and false if we were so inclined, it's not that long of a file.

from zig.

Thanks for the recatogrization, I wasn't sure if it was a bug or proposal.

I don't know how the tags work, so maybe this is correct anyways, but I didn't invoke zig translate-c at any point, this is just from @cImport() and @cInclude()

from zig.

I've uncovered even weirder behaviour. In stdbool.h, we have bool defined by #define bool _Bool, so I figured if I overrode this by putting

    @cInclude("stdbool.h");
    @cUndef("bool");
    @cDefine("bool", "int");

To the top of the @cImport() statement i would force zig to define @"bool" = c_int so that the example works,

It doesn't work. Still defines @"bool" = bool. However, wherever bool is used as part of a struct, it now uses c_int.

Totally unsure what's going on now. Is mapping C bool to zig bool hard-coded? Is re-#defineing things not supported?

from zig.

Okay, it seems indeed that this is a general thing. any time you have

const c = @cImport({
  @cDefine("foo", "1");
  @cUndef("foo");
  @CDefine("foo", "2");
});

It's going to correctly apply the second #define in any C code @cIncluded later on (replacing foo with 2), but if you access that as a variable from zig, it will go with the first definition (c.foo == 1).

I can't tell how much of this is intentional design vs. bugs. #defines don't actually have the same semantics as const declarations, but my intuition is that whatever the last #define declaration is, that one should determine how it shows up in the zig code, since that's how it would show up in C code with the same set of #includes and #defines

from zig.

It generates

pub const @"true" = @import("std").zig.c_translation.cast(bool, @as(c_int, 1));
pub const @"false" = @import("std").zig.c_translation.cast(bool, @as(c_int, 0));

Which is kind of goofy, but does work.

from zig.