[kaffeine] Patch for gcc6 and cmake changes

Mamoru TASAKA mtasaka at fedoraproject.org
Thu Jun 30 04:28:58 CEST 2016


Hello, again:

> 差出人: "Orcan Ogetbil" <oget.fedora at gmail.com>
> 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).

> Thanks for guiding to the conventions of the new standard.
> Cheers,
> Orcan
> 
> [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4296.pdf
>

Regards.
Mamoru


More information about the rpmfusion-developers mailing list