[rcore] ScanDirectoryFiles() and ScanDirectoryFilesEx() creates dependency on module rtext

[mannikim]

the functions ScanDirectoryFiles() and ScanDirectoryFilesEx() both use the function TextFindIndex() which is defined in rtext.c, and requires the flags SUPPORT_MODULE_RTEXT and SUPPORT_TEXT_MANIPULATION to be defined

this pull request introduces #if directives to prevent the use of TextFindIndex by disabling filtering directories in these functions

[sleeptightAnsiC]

Shouldn't this just use a LibC equivalent of TextFindIndex() which would be slightly modified strstr() ?

The rest of ScanDirectoryFiles/Recursively() already uses LibC calls from <string.h> so someone made sure to decouple it from rtext and probably forgot about this one single function.

Adding #if around single branch would only silently break those as files->count will not be properly incremented.

[mannikim]

Shouldn't this just use a LibC equivalent of TextFindIndex() which would be slightly modified strstr() ?

that would be a good alternative, since it would retain the directory filtering feature. i was afraid of changing the code too much

Adding #if around single branch would only silently break those as files->count will not be properly incremented.

the pointer only increments if the filter string contains DIR. since the idea was to deactivate this feature if SUPPORT_TEXT_MANIPULATION is off, it is working as intended, as you wouldn't be able to compile without it anyways
also, i couldn't find any use of this feature through the rest of the library, so there is nothing breaking internally

[raysan5]

@sleeptightAnsiC Considering rcore is already dependant on string.h, decoupling it from rtext would be a better addition than this PR.

[sleeptightAnsiC]

@mannikim (see Ray's message) Would you like to create another PR for this? It just requires swapping TextFindIndex() with strstr() and slightly modifying those checks there. I was about to fix this myself but thought you may wanna contribute? :) Tag me in case you need some help.

[mannikim]

@raysan5 i made a new pull request fixing it, see #4764

@sleeptightAnsiC thanks for the opportunity :)

closing it now