compiling glad clang and pedantic causes warning on windows

[mhhany2000]

when compiling glad with clang using the flag -pedantic I get these warnings:

C:/Dev/glad/include\KHR/khrplatform.h:189:9: warning: extension used [-Wlanguage-extension-token]
  189 | typedef __int32                 khronos_int32_t;
      |         ^
C:/Dev/glad/include\KHR/khrplatform.h:190:18: warning: extension used [-Wlanguage-extension-token]
  190 | typedef unsigned __int32        khronos_uint32_t;
      |                  ^
C:/Dev/glad/include\KHR/khrplatform.h:191:9: warning: extension used [-Wlanguage-extension-token]
  191 | typedef __int64                 khronos_int64_t;
      |         ^
C:/Dev/glad/include\KHR/khrplatform.h:192:18: warning: extension used [-Wlanguage-extension-token]
  192 | typedef unsigned __int64        khronos_uint64_t;
      |         

these warnings do not happen on linux.

this seems to be the piece of code where the warning is generated:

EGL-Registry/api/KHR/khrplatform.h

Lines 186 to 194 in 29c4314

	/*
	* Win32
	*/
	typedef __int32 khronos_int32_t;
	typedef unsigned __int32 khronos_uint32_t;
	typedef __int64 khronos_int64_t;
	typedef unsigned __int64 khronos_uint64_t;
	#define KHRONOS_SUPPORT_INT64 1
	#define KHRONOS_SUPPORT_FLOAT 1

which is only used if _WIN32 is defined, it uses __intN types that are not standard, causing warnings.

---

How to reproduce:

1. generate glad from here
2. copy the src and include directories to the root of your project
3. create a main.cpp in the root of the project
4. add this code to main.cpp

#include <glad/glad.h>
int main() {}

5. run this command: clang++ .\src\glad.c .\main.cpp -I .\include\ -pedantic

this will cause the warnings mentioned above.

---

more info:

OS: Windows 11
clang was installed through visual studio installer (C++ Clang Compiler for Windows)
clang --version output:

clang version 18.1.8
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\Llvm\x64\bin

note sure any of this information is important to the issue but I included them just in case

[stonesthrow]

@oddhack can you look at this? see if we need a change.

This is under this :

#elif defined(_WIN32) && !defined(__SCITECH_SNAP__)

We don't have a #include here.

[stonesthrow]

@mhhany2000 we need a #if to detect when these types are not included, and #include the correct header.h file, or, if these are not defined, then we need to default to standard C types "int" and such instead. If you can help provide a recommended change, that will help, since we don't have the specific setup you are trying to address.

[mhhany2000]

@stonesthrow well the problem isn't that they aren't included or defined but that they aren't standard so -pedantic warns about them which clutters the output or doesn't compile at all if -pedantic-errors is added.
why are these windows-specific types used and not the standard fixed-width types (int32_t, int64_t, etc)? is there a benefit to using these?

maybe there should be an option to force the standard types or something?

also I don't believe there is anything special about my setup, so I assume this would happen to any other project that includes the khrplatform.h header and uses the compiler flag -pedantic

[oddhack]

@oddhack can you look at this? see if we need a change.

I don't have any ability to do Windows development. As far as "why", the header is approaching 20 years old and the compiler and language ecosystem has evolved somewhat, in addition to various vendors contributing bits to this header specific to their platform (e.g. whatever SCITECH_SNAP is which frankly I've forgotten).

A difficult to answer question is whether anything will break for someone building on an old platform when changes are made, which is why we're very cautious in updating stuff like this - fix one person's issue and you can easily create a new one for someone else. What @mhhany2000 is suggesting with conditionally using the standard types is plausible.

[mhhany2000]

little update, I tested this on msys2 with a version of clang installed through this package mingw-w64-x86_64-clang and it works fine, I believe it's because of this:

https://github.com/KhronosGroup/EGL-Registry/blob/29c4314e0ef04c730992d295f91b76635019fbba/api/KHR/khrplatform.h#L143C1-L155C34

it seems that with this compiler, the macro __GNUC__ is defined, and isn't defined when I use the msvc version of clang?
this then causes the use of the standard fixed-width types.

now I wonder why msvc-clang doesn't define __GNUC__.

[stonesthrow]

There is the generic fallback at the end of #if, #else

[stonesthrow]

Can you give us the description of "-pedantic-errors" option?