Enumerations with Underlying Type Supported?

[scienceplease]

In the out-of-line API mode of usage, are enumerations with underlying types supported (C23)? As an example, assume the C source file has:

enum color : unsigned short {
    RED = 0,
    GREEN = 1,
    BLUE = 2,
};

void f1(enum color c) { /* omitted */ };

And the ffibuilder.cdef() has:

enum color { RED, GREEN, BLUE, ... };  // Can underlying type be properly inferred?

void f1(enum color c);    
void f1(int... color c);  // Is this type of declaration preferable?

Is cffi able to infer that the underlying type of enum color is unsigned short? If not, is the use of int... required or sufficient?

[arigo]

No C23-specific feature is supported (unless it happens to be one that was supported since a long time by gcc, but that's not one).

In CFFI, all enums are assumed equal to unsigned int, int, unsigned long, or long---the first which fits. So you can't really declare the type enum color in ffi.cdef(); it would mistakenly be considered to be at least as wide as an int.

Note however that you also can't use int... in function arguments. In function arguments, you can just use a larger integer type like int. It's different than the actual C type, but for simple cases like integer function arguments in function calls, the appropriate conversion is done by the C compiler.

There are still other places where int... is not supported. A more fully guaranteed solution is to add a typedef in the C sources, because int... is supported in the corresponding typedef from cdef(), like this:

ffi.set_source("""
    #include "mystuff.h"
    typedef enum color enum_color_t;
""")
ffi.cdef("""
    typedef int... enum_color_t;
    void f1(enum_color_t c);
    // and in general never use `enum color`,
    // but always `enum_color_t` instead
""")

[arigo]

Sorry, I was wrong. It seems that CFFI correctly measures the size of the enum when you use ffi.compile(). It doesn't support the enum NAME : BASE TYPE syntax, though. You should still be able to use the plain solution by ignoring this part in the cdef:

ffi.cdef("""
    typedef enum color { RED=..., GREEN, BLUE };
    void f1(enum color c);
""")

The solution above should automatically figure out that enum color is unsigned short. Using the ... like I did, it should also figure out the correct values for RED, GREEN and BLUE, but you can also stick to the original syntax RED=0, GREEN=1, BLUE=2. The point is to drop the : unsigned short part.