From: thiago.adams@gmail.com   
      
   On 12/15/2025 1:06 PM, Tim Rentsch wrote:   
   > Keith Thompson  writes:   
   >   
   >> Thiago Adams  writes:   
   >>   
   >>> The type used by MSVC compiler seems not follow the C standard.   
   >>>   
   >>> I choose the number 2147483648 that is the next number after max   
   >>> signed i32.   
   >>>   
   >>> I was expecting "signed long long" (the next signed type) but MSVC   
   >>> instead uses unsigned long (that is 32 bits)   
   >>>   
   >>>   
   >>> #define is_type(T, E) _Generic(E, T : 1 , default:0 )   
   >>>   
   >>> static_assert(is_type(unsigned long, 2147483648));   
   >>>   
   >>> int main(){}   
   >>>   
   >>> https://godbolt.org/z/EqKWroecj   
   >>>   
   >>>   
   >>> The the standard says   
   >>> "The type of an integer constant is the first of the   
   >>> corresponding list in which its value can be represented."   
   >>>   
   >>> No suffix:  The potential types, in order, are int, long int, and   
   >>> long long int.   
   >>   
   >> Yes, that appears to be a bug.   
   >>   
   >> I tried an example myself with Visual Studio 2022.  By default, it   
   >> gives 2147483648 a type of unsigned long.   
   >>   
   >> The default configuration is "/std:c17".  I thought it might be an   
   >> "extension" that I can disable with "/Za", but astonishingly that   
   >> produces a fatal error:   
   >>   
   >> error D8016: '/Za' and '/std:c17' command-line options are   
   >> incompatible   
   >>   
   >> *Maybe* there's some combination of options that will persuade it to   
   >> behave correctly.   
   >>   
   >>> So I think when "cloning" MSVC I need to not follow the standard.   
   >>   
   >> I suppose, but it depends on why you want to clone MSVC and whether   
   >> you need to replicate its bugs.   
   >>   
   >> I don't know whether this bug has been reported to Microsoft.  If   
   >> not, it should be.   
   >>   
   >>> In GCC the type is long (that is 64 bits)   
   >>>   
   >>> https://godbolt.org/z/eTKE19r8K   
   >>   
   >> On targets with 32-bit long, it should be long long.   
   >   
   > It might be the case that the behavior observed is a consequence of   
   > Microsoft never fully embracing C99.  Under C90 rules, the type of   
   > 2147483648 (assuming 32-bit longs and unsigned longs) would indeed   
   > be unsigned long.   
      
      
   My guess they were doing this before 64bit integers were introduced.   
   Then, after 64 bits, the kept this to avoid breaking changes.   
      
   Today, when the number is not represented in a signed 64 bits, in theory   
   it should use 128 signed, but it uses 64 unsigned instead and we have a   
   warning.   
      
   For instance:   
      
   9223372036854775808   
      
   warning: integer literal is too large to be represented in a signed   
   integer type, interpreting as unsigned [-Wimplicitly-unsigned-literal]   
      
   What is interesting that C code is not portable. (nothing new, just saying)   
      
   Thiago   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)