<html><head></head><body><div class="yahoo-style-wrap" style="font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:13px;"><div id="ydp93902deeyahoo_quoted_7345305203" class="ydp93902deeyahoo_quoted">> On Friday, December 4, 2020, 9:43:20 AM EST, Christof Ressi <info@christofressi.com> wrote:
<div style="font-family:'Helvetica Neue', Helvetica, Arial, sans-serif;font-size:13px;color:#26282a;">
<div><br></div><div>> alloca() "allocates" memory on the stack. This is done by simply
incrementing the stack pointer. So it's extremely fast and - more
importantly - equally fast for all sizes.</div><div><br></div><div dir="ltr" data-setdir="false">It also requires you, the programmer, to add up the total number of possible allocations in a recursive call to the object, for supported platforms with small default stack sizes, and doing the math in your head to ensure your algorithm will never go over that stack limit, for all possible cases. Since that stack limit is many orders of magnitude smaller than the RAM on the most popular Pd platform, you're way more likely to accidentally cause crashes for your users by relying on alloca.<br></div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">Again, the ATOMS_ALLOCA macro in x_list.c is the careful, thoughtful reference for use of alloca. And even in that case there are almost certainly multiple ways to cause a crasher from it. In other words, it's nearly impossible to use alloca safely.</div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">Don't use alloca *unless* you have made worst case measurements on every other algorithm you can think of, and none of them are satisfactory. Even then, *measure* alloca to be worst-case safe and write regression tests for the recursive edge cases that could blow the stack. Chances are when you consider doing that extra work, you'll quickly think up a different algorithm that doesn't rely on alloca.</div>
<div><div id="ydp93902deeyiv3867084383"><div>
<p>> malloc(), on the other hand, actually uses the system memory
allocator which can take arbitrarily long and might even block!<br clear="none">
</p>
<div>> Generally, you should avoid using any malloc() in real-time code
paths. Instead, pre-allocate temporary buffers (e.g. in the "dsp"
method) or allocate on the stack (but note the caveats mentioned
in the other mails).</div><div><br></div><div dir="ltr" data-setdir="false">Pre-allocate.</div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">If you can't, ask on the list how to use alloca without blowing the stack. Once you crowdsource a truly safe algorithm, write tests so you catch the crashers that the crowd missed the first time around.<br></div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">To be clear-- I basically grepped for "alloca" in the current codebase, opened up x_list.c, and *assumed* because alloca is tricky that there is somehow a crasher bug. It took about 5 minutes to come up with a case that should crash on Windows.</div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">I also see it in m_binbuf.c, and I'd make the same bet it can blow the Windows stack if someone spends five minutes looking at the code. For a common building block of realtime safe algos, I shouldn't be able to make claims like these for any use of alloca I happen to find.</div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">I keep harping on this because the default description of alloca makes it sound like the quintessential building block of realtime algos. Please weigh that alluring set of seeming realtime safe benefits against the history of realtime unsafe crashers of which will likely include your use alloca.<span></span><br></div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">Best,<br></div><div dir="ltr" data-setdir="false">Jonathan</div><p>> Christof<br clear="none">
</p>
<div class="ydp93902deeyiv3867084383yqt9388310659" id="ydp93902deeyiv3867084383yqtfd83427"><div class="ydp93902deeyiv3867084383moz-cite-prefix">On 04.12.2020 03:28, Alexandre Torres
Porres wrote:<br clear="none">
</div>
<blockquote type="cite">
</blockquote></div></div><div class="ydp93902deeyiv3867084383yqt9388310659" id="ydp93902deeyiv3867084383yqtfd50387"><div><div dir="ltr">I'm using getbytes and freebytes for now, any
disadvantages over alloca?
<div><br clear="none">
</div>
<div>thanks!</div>
</div>
<br clear="none">
<div class="ydp93902deeyiv3867084383gmail_quote">
<div class="ydp93902deeyiv3867084383gmail_attr" dir="ltr">Em qui., 3 de dez. de 2020 às
20:59, David Rush <<a shape="rect" href="mailto:kumoyuki@gmail.com" rel="nofollow" target="_blank">kumoyuki@gmail.com</a>> escreveu:<br clear="none">
</div>
<blockquote class="ydp93902deeyiv3867084383gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex;">
<div dir="ltr">
<div dir="ltr">On Thu, 3 Dec 2020 at 23:15, Alexandre Torres
Porres <<a shape="rect" href="mailto:porres@gmail.com" rel="nofollow" target="_blank">porres@gmail.com</a>>
wrote:<br clear="none">
</div>
<div class="ydp93902deeyiv3867084383gmail_quote">
<blockquote class="ydp93902deeyiv3867084383gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex;">
<div dir="ltr">Hi, when compiling ELSE for camomille in
windows, me and Esteban are getting some errors.
Offending pieces of code are when trying to do things
like
<div>
<div><br clear="none">
</div>
<div><span style="color:rgb(36,41,46);font-family:SFMono-Regular, Consolas, Menlo, monospace;font-size:12px;white-space:pre-wrap;background-color:rgb(255,251,221);"> t_atom at[ac];</span></div>
</div>
</div>
</blockquote>
<div><br clear="none">
</div>
<div>If you want to maintain straight C compiler
compatibility</div>
<div><br clear="none">
</div>
<div> t_atom* at = (t_atom*)malloc(ac *
sizeof(t_atom));</div>
<div><br clear="none">
</div>
<div>but you have to remember to free(at), &cet. You
can avoid the free() if you HAVE_ALLOCA with</div>
<div><br clear="none">
</div>
<div>
<div> t_atom* at = (t_atom*)alloca(ac *
sizeof(t_atom));</div>
</div>
<div><br clear="none">
</div>
<div>if you want to do it the C++ way without a
std::vector<t_atom></div>
<div><br clear="none">
</div>
<div> t_atom* at = new t_atom[ac];</div>
<div><br clear="none">
</div>
<div>but again you will have to</div>
<div><br clear="none">
</div>
<div> delete at;</div>
<div><br clear="none">
</div>
<div>For my own externals, I write them all in C++ and use
STL. Making the change from the C-world allocation of PD
to the C++ world is not so hard, but it does involve a
tiny bit of trickery which I only justify through
expediency.</div>
<div><br clear="none">
</div>
<div>- d</div>
</div>
</div>
</blockquote>
</div>
<br clear="none">
<fieldset class="ydp93902deeyiv3867084383mimeAttachmentHeader"></fieldset>
<pre class="ydp93902deeyiv3867084383moz-quote-pre">_______________________________________________
Pd-dev mailing list
<a shape="rect" class="ydp93902deeyiv3867084383moz-txt-link-abbreviated" href="mailto:Pd-dev@lists.iem.at" rel="nofollow" target="_blank">Pd-dev@lists.iem.at</a>
<a shape="rect" class="ydp93902deeyiv3867084383moz-txt-link-freetext" href="https://lists.puredata.info/listinfo/pd-dev" rel="nofollow" target="_blank">https://lists.puredata.info/listinfo/pd-dev</a>
</pre>
</div></div></div><div class="ydp93902deeyqt9388310659" id="ydp93902deeyqtfd26976">_______________________________________________<br clear="none">Pd-dev mailing list<br clear="none"><a shape="rect" href="mailto:Pd-dev@lists.iem.at" rel="nofollow" target="_blank">Pd-dev@lists.iem.at</a><br clear="none"><a shape="rect" href="https://lists.puredata.info/listinfo/pd-dev" rel="nofollow" target="_blank">https://lists.puredata.info/listinfo/pd-dev</a><br clear="none"></div></div>
</div>
</div></div></body></html>