[rcore] Fix for undeclared function _BitScanReverse on Windows

[ChrisGrams]

This PR fixes a regression introduced in commit 0b4815b (Nov 9).

After this commit, rcore.c no longer included msf_gif.h, which previously
pulled in <intrin.h> under _MSC_VER. As a result, Clang+C99 builds on
Windows fail with _BitScanReverse undeclared.

Fix
Add explicit #include <intrin.h> under _MSC_VER in sdefl.h and sinfl.h.

Tested

• Clang on Windows 11
• -std=c99 -Werror=implicit-function-declaration

[raysan5]

@ChrisGrams I don't understand, this library is required to address a Clang issue but it's checking for a Visual Studio define (_MSC_VER) while the code involved specifies that Clang should be using a different path:

static int
sinfl_bsr(unsigned n) {
#ifdef _MSC_VER
  unsigned long uln = 0;
  _BitScanReverse(&uln, n);
  return (int)(uln);
#else // defined(__GNUC__) || defined(__clang__) || defined(__TINYC__)
  return 31 - __builtin_clz(n);
#endif
}

I personally prefer to minimize libraries addition but, in any case, this change should be reported to https://github.com/vurtun/lib, to avoid beeing overriden on update. Also comment should not make referencee to rcore raylib modulee, considering is an external library.

[ChrisGrams]

@raysan5 If one uses the version of Clang installed with Visual Studio, _MSC_VER is also defined. In your code snippet, the compiler doesn't get to __builtin_clz() because _MSC_VER is defined. The intrin.h header is not included, so we get the undefined function error.

You are of course correct to point out that it's best not to modify external code. I apologize for the poorly placed patch. Perhaps it would be better to place this in the rcore.c file?

#if defined(SUPPORT_COMPRESSION_API)
    #ifdef _MSC_VER
    #include <intrin.h>
    #endif

    #define SINFL_IMPLEMENTATION
    #define SINFL_NO_SIMD
    #include "external/sinfl.h"     // Deflate (RFC 1951) decompressor

    #define SDEFL_IMPLEMENTATION
    #include "external/sdefl.h"     // Deflate (RFC 1951) compressor
#endif

[raysan5]

@ChrisGrams It should be reported to original author, not patched on raylib side.

[ChrisGrams]

@raysan5 I agree and I did submit a PR there as well.

I don't use GitHub very often, and I probably went about this the wrong way for which I apologize. My purpose was simply to notify you of a minor problem and give you a workable solution. I do appreciate your time and patience, looking over this small patch. Thank you.

[hanaxars]

@Raysan unfortunately LLVM on windows defines _MSC_VER (also clang defines __GNUC__ pretending to be gcc compiler afaik)
https://stackoverflow.com/questions/38499462/how-to-tell-clang-to-stop-pretending-to-be-other-compilers

Replacing those #ifdef _MSC_VER with #if defined(_MSC_VER) && !defined(__llvm__) && !defined(__INTEL_COMPILER) probably can solve the issue without including any libraries. Instead of _BitScanReverse it will use __builtin_clz .

raylib/src/external/sdefl.h

Lines 201 to 206 in 84737a9

	#ifdef _MSC_VER
	unsigned long msbp = 0;
	_BitScanReverse(&msbp, (unsigned long)n);
	return (int)msbp;
	#elif defined(__GNUC__) || defined(__clang__)
	return (int)sizeof(unsigned long) * CHAR_BIT - 1 - __builtin_clzl((unsigned long)n);

raylib/src/external/sinfl.h

Lines 174 to 179 in 84737a9

	#ifdef _MSC_VER
	unsigned long uln = 0;
	_BitScanReverse(&uln, n);
	return (int)(uln);
	#else // defined(__GNUC__) || defined(__clang__) || defined(__TINYC__)
	return 31 - __builtin_clz(n);

@ChrisGrams there is already a PR about the same issue with _BitScanReverse since 16th august on the original author's GitHub. But the last commit was 8 months ago so it is not so active, probably it may take some time to fix this.

Alternatively you can try to compile with -U_MSC_VER for now.

[raysan5]

@hanaxars Thanks for the proposed solution, just implemented it to avoid including an additional library in a specific case it shouldn't be required.