From: thiago.adams@gmail.com   
      
   Em 19/12/2025 09:15, Keith Thompson escreveu:   
   > Thiago Adams  writes:   
   >> Em 02/09/2025 17:10, Thiago Adams escreveu:   
   >>> 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.   
   >>   
   >> For some reason GCC and clang have a warning (integer literal is too   
   >> large to be represented in a signed integer type) only for decimal   
   >> form.   
   >>   
   >> We have a warning for 18408377700990114895 but not for the same number   
   >> written as hex 0xff77b1fcbebcdc4f.   
   >   
   > Yes.   
   >   
   > gcc's warning for 18408377700990114895 (which is slightly smaller   
   > than 2**64) is "integer constant is so large that it is unsigned".   
   > This is *incorrect* (and I think it's been reported as a bug), but   
   > the incorrect wording of the warning is not a conformance issue.   
   >   
      
   I am not understating why do you think this is a bug?   
   Because it should not compile?   
      
   > (I'm assuming long long is 64 bits.  It can be wider, at least   
   > theoretically.)   
   >   
   > In C99 and later, an unsuffixed decimal constant is always of some   
   > signed type, the smallest of int, long, and long long in which it   
   > fits -- or of an extended integer type, but gcc doesn't have those.   
   > Since 18408377700990114895 exceeds LLONG_MAX, it has no type, and   
   > is a constraint violation. (In C90, the list was int, long, unsigned   
   > long, which is the source of the wording of the warning message.)   
   >   
   > An unsuffixed hex constant can be of type int, unsigned int, long   
   > int, unsigned long int, long long int, or unsigned long long int   
   > (or an extended integer type).  Since 0xff77b1fcbebcdc4f is greater   
   > than LLONG_MAX and less than (or equal to) ULLONG_MAX, it's of type   
   > unsigned long long int, and no diagostic is needed.   
   >   
   > [...]   
   >   
   >> But I don't think hex is especial in this case.   
   >   
   > It is.   
   >   
   >> unsigned long long u[] = {18408377700990114895 , 0xff77b1fcbebcdc4f};   
   >>   
   >> I think a suffix ULL maybe useful in this case.   
   >   
   > This:   
   >   
   > unsigned long long u[] = {18408377700990114895ULL, 0xff77b1fcbebcdc4fULL};   
   >   
   > is valid.  The ULL suffix on the hex constant isn't strictly   
   > necessary, but it certainly doesn't hurt.  (If unsigned long long is,   
   > say, 128 bits and long is 64 bits, an unsuffixed 18408377700990114895   
   > will be of type long long, and an unsuffixed 0xff77b1fcbebcdc4f   
   > will be of type unsigned long, both of which will be implicitly   
   > converted to unsigned long long.)   
   >   
   > For that matter, just a "U" suffix would suffice.  A decimal constant   
   > with a "U" suffix is of type unsigned int, unsigned long int, or   
   > unsigned long long int.   
   >   
   > See N1570 6.4.4.1 or N3220 6.4.4.2.   
   >   
      
   Thanks...yes I can see a table on n3220.   
      
      
   "The type of an integer constant is the first of the corresponding list   
   in which its value can be represented"   
      
   Octal, Hexadecimal or Binary Constant   
      
   int   
   unsigned int   
      
   long int   
   unsigned long int   
      
   long long int   
   unsigned long long int   
      
   I was something that I was not expecting but but the specification is   
   very clear.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)