>>54
Oh holy fuck, I didn't actually fully interpret the depth of this post the first time around. You think that having a pointer to a stack variable and then calling a function that overwrites it is a 'random boundary case'?
Honestly. You are seriously fucking retarded. You know when you build -Wall -pedantic and the compiler gives you hundreds of warnings? Those aren't a joke. You are seriously fucking up. In my last two jobs, I introduced the policy of building everything -Wall, and it all has to come out no warnings to ship.
Also what the fuck makes you think
>>51 is fastest at run-time? It doesn't fucking do anything except give you a pointer to a literal, applied dangerously somewhere on the stack. None of these examples even make any sense. It certainly hasn't allocated an array; it has fuck all even to do with arrays.
And 'allocating an array' is an extremely generic concept; you can't just point at some code and say which is fastest. How big does the array need to be? Is it thread-local? Small? Function scoped? Then you can probably alloca() it. Is it small but shared? Consistent size? You can maybe pool it. Threaded? Add locks to the pool. Is it fairly large? malloc(). Quite large? mmap().
Honestly though all of this is superfluous. malloc() is going to be your best bet in almost all situations, since a good malloc() does all the above for you except stack allocations (which often cause more problems than they solve). You can never figure out the best way to do these things besides profiling, and honestly you always have bigger bottlenecks (like the fact that you have allocations outside of loading in the first place). The allocator is all powerful; trust the allocator.
Please tell me what your games are so I can avoid their bugs and security vulnerabilities.