[cfe-dev] Error when testing clang with VC++ RTL and Boost MPL
Edward Diener
eldlistmailingz at tropicsoft.com
Wed Nov 13 19:53:45 PST 2013
On 11/13/2013 7:59 PM, Karen Shaeffer wrote:
> On Wed, Nov 13, 2013 at 04:29:27PM -0700, Richard wrote:
>>
>> In article <l610fi$4sj$3 at ger.gmane.org>,
>> Edward Diener <eldlistmailingz at tropicsoft.com> writes:
>>
>>> Is not -1 in the range of an 'int' ?
>>
>> Yes, but you didn't write -1 in your source file.
>>
>>> Is not 0xffffffff equivalent to -1
>>> as a signed value ?
>>
>> No. They are two different integer literals.
>>
>>> What am I missing here ?
>>
>> Read the mentioned section of the standard carefully. I've read this
>> part and it isn't particularly confusing or difficult.
>
>
> Hello,
> My interpretation of this is that 2.14.2 defines how the compiler interprets the
> literal. That isn't the problem though. The problem arises, when you attempt to
> implicitly convert the compiler's interpretation to a signed integer. And the
> error is narrowing. clang emits this error:
>
> hexLiteralsUnsigned.cpp:16:24: error: constant expression evaluates to 4294967295 which cannot be
> narrowed to type 'int' [-Wc++11-narrowing]
> signed int isigned{0xFFFFFFFF};
>
> You can avoid this error by simply using a cast:
> signed int isigned{static_cast<signed int>(0xFFFFFFFF)};
>
> FYI, g++-4.8.1 only emits a warning about the narrowing, then successfully completes the
> compilation. Based on the standard section 8.5.4, I believe clang is correct to emit the
> error. And 5.17.9 declares an assignment, such as 'int i = {0XFFFFFFFF};' to be a narrowing
> error as well. I believe clang is correct to emit a narrowing error.
That is OK, now that I understand it. Interesting enough, however, if I
use '0xffffffffL' I still get an error from clang but if I use
'static_cast<long>(0xffffffff)' everything is fine. That is a difference
I would never have suspected, but at least I know now it is there.
More information about the cfe-dev
mailing list