Translate-C: type of enum value does not match type of enum

[arctic-marmoset]

Zig Version

0.14.0-dev.1320+492cc2ef8

Steps to Reproduce and Observed Behavior

Given the following header:

// header.h
enum MyEnum {
    MyEnumValue,
};

zig translate-c header.h produces the following output:

// -snip-
pub const MyEnumValue: c_int = 0;
pub const enum_MyEnum = c_uint;
// -snip-
pub const MyEnum = enum_MyEnum;

Expected Behavior

@TypeOf(MyEnumValue) should equal MyEnum.

In particular, I would have expected MyEnum to be c_int as well.

[Vexu]

They aren't the same type in C:

_Static_assert(__builtin_types_compatible_p(enum MyEnum, unsigned int));
_Static_assert(__builtin_types_compatible_p(__typeof__(MyEnumValue), int));
_Static_assert(!__builtin_types_compatible_p(enum MyEnum, __typeof__(MyEnumValue)));

[arctic-marmoset]

Ah right, I forgot the underlying type of an enum is implementation-defined (and not necessarily int) if not explicitly specified.

I also didn't know enum constants don't take the type of the enum, which I find to be surprising.

Apologies for the false alarm. Closing.

[arctic-marmoset]

I'm getting bitten by this again in the following code:

const depth_format = c.WGPUTextureFormat_Depth32Float;
const depth_texture = c.wgpuDeviceCreateTexture(device, &.{
    .viewFormatCount = 1,
    .viewFormats = &depth_format,
});

Which exhibits different behaviour on different platforms.
On Windows MSVC, this compiles without error, but on macOS it fails:

error: expected type '[*c]const c_uint', found '*const c_int'
    .viewFormats = &depth_format,

I can get around this by explicitly giving depth_format the type c.WGPUTextureFormat.

I wonder if it would cause any issues to have translate-c declare enum constants to have the same type as the enum?

[Maarrk]

I just ran into the same problem. But you can get enum type to be c_int if there's a negative value defined.

The rules for determining what type is required to fit all the declarations seem to be handled by clang. The choice when both types would work seems to be a bit arbitrary, because with larger sizes, the unsigned declaration is also used for values.

typedef enum Natural {
  NATURAL_ZERO = 0,
  NATURAL_ONE = 1,
} Natural_t;

typedef enum Both {
  BOTH_MINUS = -1,
  BOTH_ZERO = 0,
  BOTH_PLUS = 1,
} Both_t;

typedef enum Big {
  BIG_63BIT = 0x7FFFFFFFFFFFFFFF,
} Big_t;

typedef enum Bigger {
  BIG_64BIT = 0xFFFFFFFFFFFFFFFF,
} Bigger_t;

pub const NATURAL_ZERO: c_int = 0; // The value is signed
pub const NATURAL_ONE: c_int = 1;
pub const enum_Natural = c_uint; // The enum is unsigned
pub const Natural_t = enum_Natural;
pub const BOTH_MINUS: c_int = -1;
pub const BOTH_ZERO: c_int = 0;
pub const BOTH_PLUS: c_int = 1;
pub const enum_Both = c_int; // Now the enum is also signed
pub const Both_t = enum_Both;
pub const BIG_63BIT: c_ulong = 9223372036854775807; // Now the value is unsigned, even though it fits in signed type
pub const enum_Big = c_ulong;
pub const Big_t = enum_Big;
pub const BIG_64BIT: c_ulong = 18446744073709551615; // The value must be unsigned to fit in 8 bytes
pub const enum_Bigger = c_ulong;
pub const Bigger_t = enum_Bigger;

zig/src/translate_c.zig

Line 1094 in 4b910e5

const int_type = enum_decl.getIntegerType();

zig/src/zig_clang.cpp

Lines 2642 to 2644 in 4b910e5

	ZigClangQualType ZigClangEnumDecl_getIntegerType(const ZigClangEnumDecl *self) {
	return bitcast(reinterpret_cast<const clang::EnumDecl *>(self)->getIntegerType());
	}

https://clang.llvm.org/doxygen/classclang_1_1EnumDecl.html#ab8f8dbfacc727d6936dc4e196b5d3922