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

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]