Avoid GC allocation when building the search path

[ryuukk]

No description provided.

[dlang-bot]

Thanks for your pull request and interest in making D better, @ryuukk! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

• My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
• My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
• I have provided a detailed rationale explaining my changes
• New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

---

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + druntime#3391"

[Geod24]

Suggested change

	private size_t generateSearchPath(char[] path)
	private size_t generateSearchPath(ref char[MAX_PATH] path)

Otherwise one could pass null here.

[n8sh]

This size is wrong: the "search path" being generated is a concatenation of semicolon-separated paths each of which individually has (EDIT: presumably) that path limit.

[Geod24]

Then we can't really avoid GC allocations, can we ? We could however use malloc.

[ryuukk]

I made some changes after reading your messages, it is now done in 2 pass, 1st to get the size needed, then i create the array with malloc, i don't know if that is how it should be done

[kinke]

I guess a reasonable stack size would be char[MAX_PATH * defaultPathList.length] temp. Doing it in a single pass and only resorting to a heap allocation + 2nd pass in case that size doesn't suffice (very unlikely) would be ideal.

[thewilsonator]

if the point is to avoid GC allocation, please mark is @nogc so it is obvious.

[atilaneves]

Where was the GC allocation happening before?

[ryuukk]

Where was the GC allocation happening before?

string stuff

---

I bit of context, i'm trying to enforce a nogc globally using:

hack

    extern (C) __gshared string[] rt_options = ["gcopt=initReserve:0"];

    extern (C) void* gc_malloc(size_t sz, uint ba = 0, const TypeInfo = null)
    {
        import core.stdc.stdio: printf;
        import core.stdc.stdlib: abort;
        printf("no gc_malloc\n");
        abort();
        return null;
    }

    extern (C) void* gc_calloc(size_t sz, uint ba = 0, const TypeInfo = null)
    {
        import core.stdc.stdio: printf;
        import core.stdc.stdlib: abort;
        printf("no gc_calloc\n");
        abort();
        return null;
    }

    extern (C) auto gc_qalloc(size_t sz, uint ba = 0, const TypeInfo = null)
    {
        import core.stdc.stdio: printf;
        import core.stdc.stdlib: abort;
        printf("no gc_qalloc\n");
        abort();
        return 0;
    }

Works fine when i don't init the runtime extern(C) int main()

I now want to init the runtime, so i'm trying to remove all the GC allocations, so i can keep use this hack

This PR is small because it's my trying to learn the workflow to contribute

[RazvanN7]

@ryuukk Currently, this is failing the autotester.

[Temtaime]

consider return null

[RazvanN7]

ping @ryuukk

[RazvanN7]

It is wasteful to iterate defaultPathList twice. You can integrate this loop in the one above.