[kaffeine] Patch for gcc6 and cmake changes

[Orcan Ogetbil]

On 29 June 2016 at 22:28, Mamoru TASAKA  wrote:
> Hello, again:
>
>> 差出人: "Orcan Ogetbil"
>> On 29 June 2016 at 00:10, Mamoru TASAKA wrote:
>> > Hello:
>> >> 差出人: "Orcan Ogetbil"
>> >> On 27 June 2016 at 02:57, Leigh Scott  wrote:
>> >> > commit ed8b668fc05a7f626d5d34e779f58be200b7884c
>> >> > Author: leigh123linux
>> >> > Date:   Mon Jun 27 07:57:17 2016 +0100
>> >>
>> >> > +-              char cmd[] = { 0xe0, 0x31, 0x6b, config->lnbNumber };
>> >> > ++              char cmd[] = { char(0xe0), 0x31, 0x6b,
>> >> > char(config->lnbNumber) };
>> >>
>> >> Hi, this looks like a compiler bug to me. I don't see anything
>> >> ambiguous in the first line. Are we sure the compilation error is the
>> >> intended behavior?
>> >>
>> >> Thanks,
>> >> Orcan
>> >>
>> >
>> > I guess kaffeine is C++ and converting 0xe0 (this is (int)224) to char is
>> > narrowing conversion, and implicit narrowing conversion on array
>> > initialization
>> > is forbidden with gcc6 (i.e. C++14), so now gcc now makes the original
>> > error.
>>
>> I see. That makes sense. But I think the problem is with
>> config->lnbNumber instead of 0xe0 (I didn't look into the source code,
>> this is my guess).
>> The standard [1] says (page 239):
>>
>> "A narrowing conversion is an implicit conversion
>> (7.4)
>> from an integer type or unscoped enumeration type to an integer type
>> that cannot represent all the
>> values of the original type, except where the source is a constant
>> expression whose value after integral
>> promotions will fit into the target type."
>>
>> Constant int 224 is within range for char as far as I know so it would
>> fit into char. Thus, if my interpretation is right, it should not be
>> considered narrowing conversion.
>
> Well, "char" is signed by default on x86_64, so char range is
> -128 <= char <= 127. So (int)224 is out of char range.
>
> Note that char is unsigned by default on arm, so
> char foo[] = {-1, -1}; fails with C++14 on arm (but not on x86_64).
>

Aha. That's the catch. My (wrong) interpretation was 224 could be
represented by 8 bits, I didn't think about signature.

Thanks folks,
Orcan