I’ve changed/fix these issues on my build, but they should be default
To re-create the issue:
Set the default calling convention on 32-bit builds to __fastcall and re-compile.
1>src\monitor.c(75): error C2440: ‘function’: cannot convert from ‘int (__fastcall *)(const void *,const void *)’ to 'int (__cdecl *)(const void *,const void *)'
1>src\monitor.c(75): warning C4024: ‘qsort’: different types for formal and actual parameter 4
1>src\win32_joystick.c(427): error C2440: ‘function’: cannot convert from ‘int (__fastcall *)(const void *,const void *)’ to 'int (__cdecl *)(const void *,const void *)'
1>src\win32_joystick.c(427): warning C4024: ‘qsort’: different types for formal and actual parameter 4
Line 75 and 427 should FORCE/HARD CODE the calling convention to __cdecl!
win32_joystick.h: line 163
static int compareJoystickObjects(const void* first, const void* second)
to
static int __cdecl compareJoystickObjects(const void* first, const void* second)
monitor.h: line 40
static int compareVideoModes(const void* fp, const void* sp)
to
static int __cdecl compareVideoModes(const void* fp, const void* sp)
These functions are passed to qsort which expects them in a specific calling convention! If you change the default calling convention you will get the error. They need to be HARD CODED!
Thanks!
Should I make the following change …
internal.h
line 963:
int _glfwCompareVideoModes(const GLFWvidmode* first, const GLFWvidmode* second);
to
int __cdecl _glfwCompareVideoModes(const GLFWvidmode* first, const GLFWvidmode* second);
What change must I make in internal.h for the compareJoystickObjects ?
If you want to change the calling convention of your own code you shouldn’t need to alter the calling convention for GLFW as it uses the APIENTRY to define all external API entry points. You will just need to make sure that you use the same default calling convention for your glfw callbacks as the build for glfw uses (which is __cdecl).
GLFW functions themselves are sufficiently infrequently called to not need to pass their arguments via registers.
Note that if the proposal to change the calling convention for glfw internal functions was accepted, we’d need to add platform compatible defines in general code such as monitor.c.
The best place for such a proposal would probably be via a Github issue or a Github pull request.
Hi Doug,
I think these 2 functions are used by queue as callbacks for sorting. I have no problem with any other functions inside GLFW. AFAIK, these 2 functions are NOT externally visible. Have a look where they are used!
I compile GLFW to be statically linked, so when I change the default calling convention, for all the GLFW’s externally visible functions I have no problem. But these functions are only used used internally (I believe). And the problem is queue expects them as __cdecl, it has nothing/little to do with the default GLFW calling convention, this has to do with GLFW usage/compatibiliy with the queue callback.
If I create a Windows callback function, eg. WndProc. I need to make sure the calling convention for this specific function never changes (even if I change the default calling convention of my app) because windows expects the callback to be using a (hard-coded / specific) calling convention, the only way to do this is by hard coding the callbacks calling convention, so when I change my applications default calling convention to __stdcall, __fastcall, __vectorcall etc. The WndProc stays compatible with the expected calling convention of windows. The same thing applies to these functions.
Anyways, it was just an observation, I’ll just keep making these 2 changes. I don’t know what a Github issue or pull request is. I just use your forum. No worries!
I think you misunderstood what I was saying, I meant that you can set the default calling convention of your own code without changing the calling convention of GLFW even if you are statically linked.
To find out what a Github issue or pull request is, click on the links in my previous post 