regression: Mismatching types for an enum and its members

[sagehane]

Versions

Tested on NixOS with

    .version = "0.16.0-dev.747+493ad58ff",
    .dependencies = .{
        .translate_c = .{
            .url = "git+https://github.com/ziglang/translate-c#d698816184885c9cf7eaa04e8d27cf3855f368d3",
            .hash = "translate_c-0.0.0-Q_BUWlqMBgC96AnDdjyMJp6VxKT1jIcXPQCtFLYwkjBQ",
        },
    },

using both zig translate-c and the package here. I presume I'm supposed to be reporting these type of things in this repo instead of the Zig repo.

How to reproduce

Translate an enum without a fixed underlying type with zig translate-c or the header translation example in the README:

enum Foo { bar, baz };

enum Foo { bar = 0, baz = -1U };

enum Foo { bar = 0, baz = -1LU };

Expected Behaviour

The type of bar and baz ought to be equal to enum_Foo.

Actual Behaviour

enum_Foo seems to always be unsigned and the members seem to use the smallest type that can fit them.

pub const __builtin = @import("std").zig.c_translation.builtins;
pub const __helpers = @import("std").zig.c_translation.helpers;

pub const bar: c_int = 0;
pub const baz: c_int = 1;
pub const enum_Foo = c_uint;

pub const __VERSION__ = "Aro aro-zig";
// <omitted>

pub const __builtin = @import("std").zig.c_translation.builtins;
pub const __helpers = @import("std").zig.c_translation.helpers;

pub const bar: c_int = 0;
pub const baz: c_uint = 4294967295;
pub const enum_Foo = c_uint;

pub const __VERSION__ = "Aro aro-zig";
// <omitted>

pub const __builtin = @import("std").zig.c_translation.builtins;
pub const __helpers = @import("std").zig.c_translation.helpers;

pub const bar: c_int = 0;
pub const baz: c_ulong = 18446744073709551615;
pub const enum_Foo = c_ulong;

pub const __VERSION__ = "Aro aro-zig";
// <omitted>

If my understanding is correct, the first example should translate to enum_Foo = c_int and the latter two examples should have the type of bar instead be the type of baz.

Notes

enum Foo : long { bar = 0, baz = 1 };

As stated earlier, everything seems to work as expected when specifying the underlying data type (C23 feature):

pub const __builtin = @import("std").zig.c_translation.builtins;
pub const __helpers = @import("std").zig.c_translation.helpers;

pub const bar: c_long = 0;
pub const baz: c_long = 1;
pub const enum_Foo = c_long;

pub const __VERSION__ = "Aro aro-zig";
// <omitted>

[sagehane]

I just tested with Zig 0.15.2 and this seems to partially be a regression:

enum Foo { bar, baz };

// <omitted>
pub const bar: c_int = 0;
pub const baz: c_int = 1;
pub const enum_Foo = c_uint;
// <omitted>

This header seems to have the same issues.

---

enum Foo { bar = 0, baz = -1U };

// <omitted>
pub const bar: c_uint = 0;
pub const baz: c_uint = 4294967295;
pub const enum_Foo = c_uint;
// <omitted>

This header actually doesn't have a type mismatch.

[ehaas]

Is this a regression compared to the clang-based translate-c? Just eyeballing the examples they seem correct - by default in C the type of an enum does not necessarily match the type of the corresponding enumerators. The enum type just needs to be capable of storing every enumerator value. There's also the -fshort-enums option to make it use the smallest enum type that can hold all of the enumerator values.

[Vexu]

It's not standard compliant:

15 The enumeration member type for an enumerated type without fixed underlying type upon completion is:
— int if all the values of the enumeration are representable as an int; or,
— the enumerated type. 140)

enum Foo { bar = 0, baz = -1LU };
_Static_assert(__builtin_types_compatible_p(__typeof(bar), unsigned long));

[ehaas]

We're the same as GCC and clang here, right? That _Static_assert fails for me in all 3. Do we need a flag for standards-compliant enum behavior?

[sagehane]

Welp, did I misunderstand the C spec? An excerpt of the C23 spec on https://en.cppreference.com/w/c/language/enum.html says:

All enumerations have an underlying type. The underlying type can be explicitly specified using an enum-type-specifier and is its fixed underlying type. If it is not explicitly specified, the underlying type is the enumeration’s compatible type, which is either a signed or unsigned integer type, or char.

This suggests that the underlying type is implementation-defined and the first case of c_int elements with c_uint underlying type seems valid. But the other cases conflicting with the previous Clang-based translate behaviour seems like a genuine bug.

Though I don't see why GCC or Clang apparently is choosing unsigned int when it could choose char (smallest type to fit all elements) or int (the actual type of the elements).

[Vexu]

We're the same as GCC and clang here, right? That _Static_assert fails for me in all 3. Do we need a flag for standards-compliant enum behavior?

It passes for me with GCC and clang and fails with aro.

Though I don't see why GCC or Clang apparently is choosing unsigned int when it could choose char (smallest type to fit all elements) or int (the actual type of the elements).

It's implementation defined so I guess they're choosing unsigned because there are no negative enumerators, if you make the enum packed they will use smaller types. MSVC will use int for enums without negative enumerators as well.

[ehaas]

Ah, I was using older versions (e.g. clang 17 on macos). Checking on godbolt I see that clang and gcc both pass.