There is no ISO C definition of opendir(), that's a POSIX thing.
But yeah, those DIR objects which opendir() returns a pointer to are probably some kind of heap allocated. But we're talking about a system call involving the filesystem here. The time taken by the allocator is gonna be dwarfed by the time spent in the syscall even with the slowest allocator.
Ripgrep reads through every byte of most files and matches it against a regex. That is the tight inner loop where you want to avoid allocations.
Not that you even need to call the C functions. I don't think ripgrep would gain anything from it, but the syscall to read directory contents just needs a file descriptor.
I think ripgrep does avoid allocations in that innermost loop. That's why this report says all the crashes are associated with opendir() and its memory allocation: the opendir() call is outside of ripgrep's innermost loop but still runs often enough to trigger the race condition.
And that's why musl's allocator's performance isn't a huge concern for ripgrep
That's to be properly measured. Assuming that the allocator will not cause issues there is to be proven.
The application I recently improved by changing the allocator had a similar profile (a C++ include scanner) and thread parallel I/O functions had terrible performance originally with mallocng. Adding threads almost had negative value because of the contention.