[cfe-dev] MS 128-bit literals don't always have the correct type

David Blaikie dblaikie at gmail.com
Tue Oct 2 08:47:00 PDT 2012


On Sun, Sep 23, 2012 at 9:37 PM, Richard Smith <richard at metafoo.co.uk> wrote:
> On Sun, Sep 23, 2012 at 1:45 PM, Dmitri Gribenko <gribozavr at gmail.com>
> wrote:
>>
>> On Sun, Sep 23, 2012 at 11:41 PM, Stephen Canon <scanon at apple.com> wrote:
>> > On Sep 23, 2012, at 4:20 PM, Dmitri Gribenko <gribozavr at gmail.com>
>> > wrote:
>> >
>> > Yes, currently it is misleading and just bad to turn on
>> > -fms-extensions if one wants 128-bit literals.  Since this is not an
>> > MS extension, code using this feature does not need other MS
>> > extensions.
>> >
>> > Should support be enabled by default as a clang extension?
>>
>> I would say yes, but since a new kind of integer literal is such a big
>> thing, we definitely need a comment from our honorable C++ language
>> layers who working on Clang.
>
>
> There are three interactions with language law that seem relevant here:
>
> 1) C99 and C++11 have a notion of "extended integer types", which allows for
> an integer literal (with or without a suffix) to be given a type larger than
> any standard integer type, if it would be too large to fit in any relevant
> standard integer type. We are not required to give __int128 this treatment,
> but are permitted to do so. If we treated __int128 as an extended integer
> type, we wouldn't need a suffix for this, except for cases where the
> programmer explicitly want to get an __int128 result for a number that would
> fit in 64 bits, and the i128 suffix does not provide us with that behavior.
>
> 2) We support a GNU extension where a decimal integer literal which doesn't
> fit in the largest standard signed type is given the largest standard
> unsigned type instead, and that directly conflicts with the newer language
> standards. This is not a conforming extension in C++11, where an
> implementation must either give the constant a signed type large enough to
> hold it, or produce a diagnostic (we get by here on a technicality, since we
> produce a warning for this case, but we currently fail to reject it in
> -pedantic-errors mode).
>
> 3) The new i128 suffix conflicts with C++11's user-defined literals.
> However, that suffix (and all others not starting with an underscore)

[love how that's kind of backwards compared to other reserved
identifiers (reserving things /with/ underscores (in various forms)
for the implementation, rather than for the user)]

> are
> reserved ("for future standardization"), so using this suffix for our own
> purposes is defying the intent of the committee, but still conforming.
>
> My recommendation is: we drop the GNU extension, implement the C99 / C++11
> extended integer type rules instead, and drop the i128 suffix.
>
> It seems unlikely that anyone was relying on the suffix, since it is
> undocumented, only works in -fms-extensions mode but isn't an MS extension,
> and relies on the GNU __int128 type but isn't implemented in GCC... and in
> any case the new rules would make it redundant.

Agreed. We have a document about how to propose/add language
extensions & i128 doesn't seem to meet the bar.

> Dropping the GNU extension could possibly impact the meaning of some (C++)
> code which cares about the type of an overlarge integer literal, so we
> should produce a diagnostic under -Wgcc-compat in the cases whose meanings
> change. These are the cases where we currently produce an "integer constant
> is so large that it is unsigned" warning (by default, with no flag to
> disable it!).

Sort of surprising no one's complained about that - seems like sort of
a reasonable use case, if I'm understanding correctly.

- David

>
> -- Richard
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>



More information about the cfe-dev mailing list