> then alloca() is IMO the best tool for the job. It is not only simpler but
> also faster than pre-allocation, because the stack memory is much more likely
> to be in cache.
I'm not sure that's quite constrained enough yet. Not only do we want to avoid
an arbitrary user-controlled upper bound, we don't want future devs adding the
"feature" of an arbitrary user-controlled upper bound, or even a new upper
bound that isn't user-controlled but is still too high given what you and I
know about alloca.
So unless those constraints are documented in the code, this is still asking
for trouble. And history of trouble is scattered throughout the usage history
of alloca in Pd and elsewhere.
I'm willing to concede that "Don't use alloca," is a bit like, "eval is evil."
But given the proliferation of wrong uses of alloca I believe it's warranted.
At least here we've gone from avoiding a call to free to a list of very niche
constraints.
Best,
Jonathan
_______________________________________________
Pd-dev mailing list
[email protected]
https://lists.puredata.info/listinfo/pd-dev
