From Newsgroup: comp.lang.c

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.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

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 */
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

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.




--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

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 */
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

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.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

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 */
--- Synchronet 3.21a-Linux NewsLink 1.2