• Custom User Avatar

    That is not how it whould be!

    But that's how it is and have been since at least 1998. Please, take a look at ISO/IEC 14882:1998 2.13.1 [lex.icon] p2:

    The type of integer literal depends on its form, value and suffix. If it's decimal and has no suffix, it has the first of these types in which its value can be represented: int, long int;

    So, of course GCC does that in this way, and I don't think it would ever change. Cheers!

  • Custom User Avatar

    In my opinion, it should use type of lvalue, x in my example. Without aditional hints.

    I checked real C compiler(GCC) - same behaivior :(

    Only with type hint LL or (int64_t) it ok. That is not how it whould be! (but who am i to judge The Standard)

    Well, i learned important thing, thanks codewars!

    Thanks MikChan, hobovsky!

  • Custom User Avatar

    That's not clang. It's C++17 standard, 5.13.2 [lex.icon] p2:

    The type of an integer literal is the first of the corresponding list in Table 7 in which its value can be
    represented.

    The list for a decimal literal with no suffix is the following:

    int
    long int
    long long int
    

    The value 2 perfectly fits into int, so any C++17 standard compliant compiler is required to interpret that as int.

  • Custom User Avatar

    except it's not CLang issue, it's how every standard compliant compiler would to it. Most probably it would also issue a compilation warning. If you want to shift more bits that size of operands, you need to promote at least one of them to something wider.

    One possible way is to use literals of appropriate type: long long x = 2LL << 33;

  • Custom User Avatar
    1. CLang is evil.
      I would expect that
      int64_t x = 2 << 33;
      will make x = 8 589 934 592, but CLang have its own idea. and u have to int64_t x = (int64_t)2 << 33;

    2. task itself is not very programish. test cases limits make memory or CPU not usable, so i have to heat up my own brain. I do not like to do that.