I'd strongly advise to avoid it in general.For general purpose code I would agree, but for realtime safe code we want to avoid dynamic memory allocation and careful use of alloca() is perfectly fine. But there are caveats.
In fact, we had a crasher in FFT objects which used temporary buffers on the stack. Users tried to do a 100 000 point FFT and it would crash on Windows. There are at least threee ways to solve this problem:
a) conditionally switch to malloc() beyond a certain size (don't forget to free the buffer :-)
b) use a pre-allocated buffer in the object
c) use thread local storage
In fact, the next time I get on a Windows machine I bet I can create a trivial Pd patch to blow the stack using only `[list prepend]` and `[list fromsymbol]`.To elaborate: The limit for ATOM_ALLOCA is 100 and the stack limit is 1000. On a 64-bit system, t_atom takes 16 bytes (including padding). This means we could have up to 1,600,000 bytes on the stack before Pd's stack protection kicks in. The default stack size on Windows is 1 MB, so it would blow up.
Christof
> You can avoid the free() if you HAVE_ALLOCA with
> t_atom* at = (t_atom*)alloca(ac * sizeof(t_atom));
If the user can control ac, then you have likely introduced a potential crasher just to avoid a call to free.
Systemd had a cve from using alloca awhile back. Pd recently fixed a crasher due to alloca. In neither case was alloca necessary.
I'd strongly advise to avoid it in general.
In fact, the next time I get on a Windows machine I bet I can create a trivial Pd patch to blow the stack using only `[list prepend]` and `[list fromsymbol]`. If so it will be 100% due to alloca, and an ostensibly defensive use of it at that. (Have a look at the code for the ATOMS_ALLOCA macro if someone wants to beat me to it.)
Best,
Jonathan
_______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev