Earlier quoted context omitted.
> Even if they're the same calling convention, that should fail, but it doesn't. It's an interesting question. According to the standard, functions with different language linkage are indeed considered different types. As a consequence, should declare two overloads for qsort() that only differ in the type of the sort function. However, modern compilers don't seem to care: "The only modern compiler that differentiates…
As long as I can't silently get wrong behavior or runtime crashes, I'm happy enough. Is it guaranteed that an incorrect calling convention will always cause a compiler error? I wasn't aware the calling convention was considered part of the pointer type. Anyway, thanks for engaging with me so earnestly. I guess I had some assumptions about calling conventions that needed to be straightened out, which is important, as…
A standard-conforming C++ compiler must not allow implicit pointer casts, so yes!
> I wasn't aware the calling convention was considered part of the pointer type.
Some well-designed C APIs define a macro for the calling convention that they add to all API functions and function pointer declarations. The user can then use the same macro when supplying their callbacks, which guarantees that the calling conventions match. (On modern platforms, the macro would be typically empty.)
Here's an example: https://github.com/Celemony/ARA_API/blob/1f68fba7a374b14df19.... As you can see, it is part of the function pointer type: https://github.com/Celemony/ARA_API/blob/1f68fba7a374b14df19...
Another famous example is, of course, the WINAPI macro in the Win32 API.
That's also what I tend to do with my own C APIs.
> I guess I had some assumptions about calling conventions that needed to be straightened out
I also learned a few things in this discussion, so thanks for that!