Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #394278 > unrolled thread

type of decimal constants in msvc

Back to article view | Back to comp.lang.c

Contents

  type of decimal constants in msvc Thiago Adams <thiago.adams@gmail.com> - 2025-09-02 17:10 -0300
    Re: type of decimal constants in msvc Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-09-02 13:46 -0700
      Re: type of decimal constants in msvc Thiago Adams <thiago.adams@gmail.com> - 2025-09-02 20:39 -0300
      Re: type of decimal constants in msvc Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-12-15 08:06 -0800
        Re: type of decimal constants in msvc Thiago Adams <thiago.adams@gmail.com> - 2025-12-15 14:03 -0300
          Re: type of decimal constants in msvc Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-15 14:14 -0800
    Re: type of decimal constants in msvc Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-09-03 06:42 +0000
      Re: type of decimal constants in msvc BGB <cr88192@gmail.com> - 2025-09-03 10:59 -0500
      Re: type of decimal constants in msvc Michael S <already5chosen@yahoo.com> - 2025-09-04 15:21 +0300
    Re: type of decimal constants in msvc Thiago Adams <thiago.adams@gmail.com> - 2025-09-03 16:04 -0300
    Re: type of decimal constants in msvc Thiago Adams <thiago.adams@gmail.com> - 2025-12-19 08:43 -0300
      Re: type of decimal constants in msvc Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-19 04:15 -0800
        Re: type of decimal constants in msvc Thiago Adams <thiago.adams@gmail.com> - 2025-12-19 09:49 -0300
          Re: type of decimal constants in msvc Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-19 12:26 -0800
            Re: type of decimal constants in msvc Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-12-22 05:05 -0800
              Re: type of decimal constants in msvc Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-22 12:01 -0800
                Re: type of decimal constants in msvc Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-01 18:32 -0800
                  Re: type of decimal constants in msvc Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-01 19:22 -0800

#394278 — type of decimal constants in msvc

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.

So I think when "cloning" MSVC I need to not follow the standard.

In GCC the type is long (that is 64 bits)

https://godbolt.org/z/eTKE19r8K

[toc] | [next] | [standalone]

#394279

Thiago Adams <thiago.adams@gmail.com> 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.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#394280

Em 02/09/2025 17:46, Keith Thompson escreveu:
> Thiago Adams <thiago.adams@gmail.com> 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.
> 


I think if it is a bug this will never be fixed this is the way it is.
When compiler run out of bigger signed type they use unsigned. GCC gives 
a warning when doing that.
maybe..the int32 was the last signed type when MS adopt it..and when int 
64 was created it was too late to update. (just a guess)

when I put max i64 + 1 gcc choses unsigned long long (64bits) instead of 
unsigned long (that is also 64 bits)

https://godbolt.org/z/1ezhjP5jE

[toc] | [prev] | [next] | [standalone]

#395816

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Thiago Adams <thiago.adams@gmail.com> 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.

[toc] | [prev] | [next] | [standalone]

#395820

On 12/15/2025 1:06 PM, Tim Rentsch wrote:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> 
>> Thiago Adams <thiago.adams@gmail.com> 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

[toc] | [prev] | [next] | [standalone]

#395825

Thiago Adams <thiago.adams@gmail.com> writes:
[...]
> 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.

In C99 and later, an unsuffixed integer constant is *never* of unsigned
type.

> For instance:
>
> 9223372036854775808

That's 2**63, likely equal to LLONG_MAX+1.

> 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)

The error message is incorrect, a bug that's been reported against gcc :

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96788

But I think that error message is from clang (gcc's message refers to
"integer constant", clang's to "integer literal").

The type of an unsuffixed integer constant is the first of (int,
long int, long long int) in which its value can be represented.
If it exceeds LLONG_MAX, it *may* be of an extended integer type;
neither gcc nor clang supports extended integer types.  Failing that,
"the integer constant has no type", which violates a constraint:
"Each constant shall have a type and the value of a constant shall
be in the range of representable values for its type."

With 64-bit gcc, 9223372036854775808 is of type __int128 -- which (a)
is not an unsigned type, as stated by the incorrect warning message,
and (b) is *not* an extended integer type.  (gcc does produce a
diagnostic, which is all that's required for a constraint violation,
but it's certainly a bug.)

With 64-bit clang, 9223372036854775808 is of type unsigned long long,
which is incorrect but at least consistent with the warning message.

#include <stdio.h>
int main(void) {
    printf("9223372036854775808 is of type %s\n",
           _Generic(9223372036854775808,
               int: "int",
               unsigned int: "unsigned int",
               long: "long",
               unsigned long: "unsigned long",
               long long: "long long",
               unsigned long long: "unsigned long long",
#ifdef __GNUC__
               __int128: "__int128",
               unsigned __int128: "unsigned __int128",
#endif
               default: "<unknown>"
               ));
}

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#394282

On Tue, 2 Sep 2025 17:10:25 -0300, Thiago Adams wrote:

> The type used by MSVC compiler seems not follow the C standard.

Does anybody use MSVC for anything important any more?

[toc] | [prev] | [next] | [standalone]

#394287

On 9/3/2025 1:42 AM, Lawrence D’Oliveiro wrote:
> On Tue, 2 Sep 2025 17:10:25 -0300, Thiago Adams wrote:
> 
>> The type used by MSVC compiler seems not follow the C standard.
> 
> Does anybody use MSVC for anything important any more?

It is one of the main compilers used for native Windows development.
Also most old code tends to work in it without too much issue, whereas 
getting old code to work in GCC and Clang often requires fixing stuff.

Also, MSVC tends to compile stuff pretty fast (at least when compiling C 
code and not using "windows.h" or similar).


But, as far as:
   Supporting newer C standards;
   Generating binaries that aren't huge / bloated;
   Being all that effective at optimization;
   ...
It is a bit more YMMV.

...

[toc] | [prev] | [next] | [standalone]

#394296

On Wed, 3 Sep 2025 06:42:29 -0000 (UTC)
Lawrence D’Oliveiro <ldo@nz.invalid> wrote:

> On Tue, 2 Sep 2025 17:10:25 -0300, Thiago Adams wrote:
> 
> > The type used by MSVC compiler seems not follow the C standard.  
> 
> Does anybody use MSVC for anything important any more?

I have no hard data, but would estimate that at least 95% of
non-python, non-AI, non-web in-house Windows development uses MS Visual
Studio. Of course, overwhelming majority of it is either various .Net
languages or native C++. C is quite rare.

For not in-house, I would think that nearly all Microsoft's own
"desktop" apps are developed with Visual Studio. It is also leading
platform for Windows games development and practically exclusive
platform for Xbox game development. Of major open-source apps, AFAIK,
Firefox for Windows is developed with Visual Studio, but I can't tell
whether it uses Microsoft's back end or the one of clang.
Once again, very few of the projects mentioned in above paragraph are
written in C.

So, if we are talking specifically about C then it's possible that by
now *for user mode* nothing of major importance is using MSVC as their
primary development environment. However I would guess that many
organizations are using it for compilation of C code developed on
non-windows platforms. Deployment of MSVC-compiled apps is simpler and
more reliable than deployment of apps compiled for Windows with gcc or
clang compilers. That does not sound important for a hobbyist, but
matters for bigger organizations.

Of course, there is also a kernel mode.
MSVC remains the only officially supported compiler in this space. So,
I would guess that over 99% of production Windows drivers developed in
C with MSVC. In the ancient past some people, myself including, used to
ignored Microsoft's guidelines and developed Windows kernel drivers in
C++. That pretty much stopped with emergence of WDF/KMDF. KMDF is
C-only and it is seriously better than any 3-rd party C++ driver
development framework. C won here over C++ not just by administrative
sanctions of MS, but also by technical merits.
It's important to point out that "kernel drivers" are not just hardware
drivers. The category includes *all* 3rd-party kernel code.
The elephants in this room are kernel components of very crappy, but
very widespread and profitable contraptions known as 'security
software'.

[toc] | [prev] | [next] | [standalone]

#394288

On 9/2/2025 5:10 PM, Thiago Adams wrote:
> 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.
> 
one interesting consequence

static_assert(-2147483638 == 2147483648 + 10, "is true");
int main(){}

https://godbolt.org/z/3Gsqananr

[toc] | [prev] | [next] | [standalone]

#395853

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.


int main(){
    static_assert(18408377700990114895 == 0xff77b1fcbebcdc4f);
}

https://godbolt.org/z/PPYErfrTP

But I don't think hex is especial in this case.

unsigned long long u[] = {18408377700990114895 , 0xff77b1fcbebcdc4f};

I think a suffix ULL maybe useful in this case.

[toc] | [prev] | [next] | [standalone]

#395854

Thiago Adams <thiago.adams@gmail.com> 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'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.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#395855

Em 19/12/2025 09:15, Keith Thompson escreveu:
> Thiago Adams <thiago.adams@gmail.com> 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.

[toc] | [prev] | [next] | [standalone]

#395860

Thiago Adams <thiago.adams@gmail.com> writes:
> Em 19/12/2025 09:15, Keith Thompson escreveu:
[...]
>> 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?

No, because the message is factually incorrect.  The integer constant
18408377700990114895 is not of any unsigned type.

Diagnosing it is correct (since 18408377700990114895 > LLONG_MAX),
but the message is incorrect.

The bug report is <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96788>.

[...]

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#395884

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Thiago Adams <thiago.adams@gmail.com> writes:
>
>> Em 19/12/2025 09:15, Keith Thompson escreveu:
>
> [...]
>
>>> 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?
>
> No, because the message is factually incorrect.

No, it isn't.  The message might be misleading but it isn't wrong.

> The integer constant 18408377700990114895 is not of any unsigned type.

The message doesn't say the constant has an unsigned type.  It says
only that the constant is unsigned.

[toc] | [prev] | [next] | [standalone]

#395890

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Thiago Adams <thiago.adams@gmail.com> writes:
>>> Em 19/12/2025 09:15, Keith Thompson escreveu:
>> [...]
>>
>>>> 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?
>>
>> No, because the message is factually incorrect.
>
> No, it isn't.  The message might be misleading but it isn't wrong.
>
>> The integer constant 18408377700990114895 is not of any unsigned type.
>
> The message doesn't say the constant has an unsigned type.  It says
> only that the constant is unsigned.

What distinction are you making?

All integer constants are "unsigned" in the sense that they don't
include a sign.  -1 is an expression, not a constant.  That's not
what the message means.

I see no reasonable interpretation of "integer constant is so
large that it is unsigned" other than that it's of an unsigned type
because it's too large.

The message correctly reflects the C90 semantics, where a
sufficiently large unsuffixed decimal integer constant is of type
unsigned long.  But in C99 and later, an unsuffixed decimal integer
constant is never of any unsigned type.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#396713

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>> Thiago Adams <thiago.adams@gmail.com> writes:
>>>
>>>> Em 19/12/2025 09:15, Keith Thompson escreveu:
>>>
>>> [...]
>>>
>>>>> 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?
>>>
>>> No, because the message is factually incorrect.
>>
>> No, it isn't.  The message might be misleading but it isn't wrong.
>>
>>> The integer constant 18408377700990114895 is not of any unsigned type.
>>
>> The message doesn't say the constant has an unsigned type.  It says
>> only that the constant is unsigned.
>
> What distinction are you making?

The distinction I'm making is between what the statement actually
says rather than how it might be interpreted.

[toc] | [prev] | [next] | [standalone]

#396715

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>> Thiago Adams <thiago.adams@gmail.com> writes:
>>>>> Em 19/12/2025 09:15, Keith Thompson escreveu:
>>>> [...]
>>>>>> 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?
>>>>
>>>> No, because the message is factually incorrect.
>>>
>>> No, it isn't.  The message might be misleading but it isn't wrong.
>>>
>>>> The integer constant 18408377700990114895 is not of any unsigned type.
>>>
>>> The message doesn't say the constant has an unsigned type.  It says
>>> only that the constant is unsigned.
>>
>> What distinction are you making?
>
> The distinction I'm making is between what the statement actually
> says rather than how it might be interpreted.

That's extremely vague.  I won't bother asking you for clarity.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web