Re: [Xen-devel] [PATCH v2] tools/libxl: libxl_get_scheduler should return an int

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

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