[Xcb] [PATCH] c_client.py: Prefer bit shifts over values in enum

[Ran Benita]

Thanks for the explanations. But bear with me a little more :)

On Tue, Jul 29, 2014 at 05:43:53PM -0400, Peter Harris wrote:
> On 2014-07-29 17:14, Ran Benita wrote:
> > On Tue, Jul 29, 2014 at 04:59:12PM -0400, Peter Harris wrote:
> >> On 2014-07-29 16:26, Daniel Martin wrote:
> >>> Any idea or wish how I should change the patch, how the resulting value
> >>> should like?
> >>
> >> 0x80000000 simply isn't representable in an enum in standard C.
> > 
> > Can you explain how this patch makes things worse in this regard?
> 
> It's signed overflow. (1 << 31) is an integer greater than INT_MAX.

But the current constant also cannot be represented in an int. So I'm
not sure how (1u << 31u) is worse?

> Note also https://gcc.gnu.org/wiki/FAQ#signed_overflow
> 
> > (You mentioned a gcc extension, which one?).
> 
> https://gcc.gnu.org/onlinedocs/gcc/Integers-implementation.html#Integers-implementation
> 
> Specifically, the two bullet points "The result of, or the signal raised
> by, converting an integer to a signed integer type when the value cannot
> be represented in an object of that type"

Again, what's the difference from the current status?

> and "The results of some
> bitwise operations on signed integers".
>
> In particular, "GCC does not use the latitude given in C99 and C11 only
> to treat certain aspects of signed ‘<<’ as undefined, but this is
> subject to change." Where 1<<31 appears to be one of the "certain
> aspects", if I read the spec correctly.

If we use (1u << 31u), this does not apply, no? You get an unsigned
constant, which needs to be coverable to an int, and you hit the
paragraph above.

> Peter Harris
> -- 
>                Open Text Connectivity Solutions Group
> Peter Harris                    http://connectivity.opentext.com/
> Research and Development        Phone: +1 905 762 6001
> pharris at opentext.com            Toll Free: 1 877 359 4866