[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2] tools/libxl: libxl_get_scheduler should return an int
Julien Grall writes ("Re: [PATCH v2] tools/libxl: libxl_get_scheduler should return an int"): > On 03/21/2014 12:43 PM, Ian Campbell wrote: > > Are there any API compatibility concerns here? I think there isn't > > because > > enum foo bar = get_foo() > > and > > int bar = get_foo() > > are both always valid whether get_foo() returns an enum foo or an int. > > > > So I think we can make this change without a LIBXL_HAVE define. Would be > > good to confirm and include the rationale in the commit log. > > C99, 6.7.2.2p4 > > Each enumerated type shall be compatible with char, a signed integer > type, or an unsigned integer type. The choice of type is > implementation-defined,108) but shall be capable of representing the > values of all the members of the enumeration. [...] This is quite a weak statement, and I don't think it's helpful as part of an argument that this change has no API implications. As you have discovered, some enums can be unsigned types. Changing the return type of this function to from an unsigned to signed type can change the meaning of the code which uses it. My justification for making this change is that where the meaning changes, it is very likely to do so in a way which better serve's the programmer's intent. > I gave a try with a simple test file: > typedef enum libxl_sched > { > SCHED_SCHED, > } libxl_sched; > > int f(void); > > int main(void) > { > libxl_sched sched = f(); > > return 0; > } > > I compiled twice, the second time I have changed f return type. > > The result is the same with gcc 4.7 on x86. For ARM with gcc 4.6.3 there > is an extra move on the first version. IHMO it's not harmfull. Here you are discussing ABI, rather than API, compatibility. A compiler which sees an enum type is allowed to assume that it's within the enum's range. That might generate different code in subtle situations. That you don't see any difference now is not conclusive. However, again, I would argue that the change is purely beneficial. Forbidding the compiler from making these assumptions about the values of objects with enum type will make the code more correct, not less. Thanks, Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |