From Newsgroup: comp.lang.c

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



--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

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

From Newsgroup: comp.lang.c

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







--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

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

From Newsgroup: comp.lang.c

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.

...

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

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

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

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