Özkan Sezer
Özkan Sezer
Should be fixed now that #11496 is in
Even with bumping `MAX_CLIP_VERTS` to 128, when I noclip'ed around after that setpos, I immediately hit the error with `nump==157`. @ericwa : Should we bump that `MAX_CLIP_VERTS` to 256 which...
OK @vsonnier, thanks. @ericwa, @andrei-drexler: thoughts?
Do we have a better solution that doesn't rape the stack?
@vsonnier: I tried applying the patch inlined below to qs, based on relevant vkquake commits. The `alloca` path is good. But the `malloc` path crashes miserably. (Tested by hard-coding `on_heap`...
OK, as far as I can see, that `+ 2` needs to be taken into account back in `Sky_ProcessPoly`, i.e. if I allocate +2 more elements in `Sky_ProcessPoly` it seems...
The problem appears not in `Sky_ProcessPoly`, but `Sky_ClipPoly` where it does `VectorCopy (vecs, (vecs+(i*3)) );` which results in a buffer overrun: I noticed that by running qs under valgrind.
I just applied the gl_sky3.patch from above to qs as e35ecad1847de7b2d3382ce180c145015cc1e379 @vsonnier: Waiting for your further comments / replies to apply the vkquake patch and close this.
The `vecs` parameter to `Sky_ClipPoly` is `vec3_t` and compiler takes that as `float *`, that's why it works and that's why access in `VectorCopy` call is not `(vecs + (nump...
Maybe we should just change `Sky_ClipPoly` to take `vecs` as `float *` instead of `vec3_t` to avoid confusions?