Re: Why keysym constants in gdk/gdkkeysyms.h are defined as macros, not as an enum?

[Mark Vender <markv743 yahoo co uk>]

On 06/26/2012 09:22 PM, Christophe Fergeau wrote:
> 2012/6/26 Mark Vender <markv743 yahoo co uk>:
> > Well, C doesn't actually have such restriction.
>
> Yes and no, if you assign an integer to a variable of an enum type,
> and if this integer is not one of the value defined for this enum
> type, then this is undefined behaviour in the C standard.

Are you sure? It's undefined behavior only if the value of the integer 
can not be represented in the underlying type of the enum. Anyway, I'm 
not suggesting to use enum type to store enum values, just as provider 
of constant values. Something like the following:

typedef enum {
    GDK_KEY_*** = <...>,
    <...>
} GdkKeyVal;

...

int keyval = GDK_KEY_***; //int, not GdkKeyVal - nothing changes

> > It's impossible for an application to break when enum values are added. They
> > end up as integers within the code anyway and unless their values change,
> > API/ABI stays the same.
>
> Again, the C standard has some gotcha there, a compiler is allowed to
> use a char-sized integer or an int-sized integer to store an enum, so
> sizeof of an enum type can change if you add more values to it, which
> could be an ABI break. And this is not purely theoretical, I think
> llvm does this.

My proposal isn't about storing values in enums, so there's no problems 
with undefined behavior. I'm only proposing to use enum constants, 
instead of macro constants, as a vehicle to inject the values into the 
global scope.

Cheers,
Mark