Hello, again:
差出人: "Orcan Ogetbil" <oget.fedora(a)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