<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Your concerns are certainly warranted.</p>
<p>But if the function is <br>
</p>
<p>a) never called recursively,</p>
<p>b) is never inlined(!)* and</p>
<p>c) the buffer size is guaranteed not to exceed some reasonable
size for stack allocation (say a few hundred bytes),</p>
<p>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.<br>
</p>
<p>Again, I wouldn't recommend using alloca() for general purpose
programming, but when used cautiously it can be a great tool for
real-time code.</p>
<p>---<br>
</p>
<p>BTW, here's an example for how alloca() might be used in a
production-grade library:
<a class="moz-txt-link-freetext" href="https://github.com/gcp/opus/blob/master/celt/stack_alloc.h">https://github.com/gcp/opus/blob/master/celt/stack_alloc.h</a></p>
<p>It uses alloca() resp. VLAs, but can fallback to a pseudo stack
for platforms without alloca()/VLA support or small stack sizes
(e.g. embedded devices).<br>
</p>
<p>Christof<br>
</p>
<p>*) IIRC, GCC refuses to inline functions if they contain alloca()
statements. What can go wrong with inlined functions containing
alloca(): <a class="moz-txt-link-freetext" href="https://stackoverflow.com/a/3410689/6063908">https://stackoverflow.com/a/3410689/6063908</a><br>
</p>
<div class="moz-cite-prefix">On 04.12.2020 16:57, Jonathan Wilkes
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:577901063.2845409.1607097475376@mail.yahoo.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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
<a class="moz-txt-link-rfc2396E" href="mailto:info@christofressi.com"><info@christofressi.com></a> 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"
moz-do-not-send="true">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"
moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">Pd-dev@lists.iem.at</a><br
clear="none">
<a shape="rect"
href="https://lists.puredata.info/listinfo/pd-dev"
rel="nofollow" target="_blank" moz-do-not-send="true">https://lists.puredata.info/listinfo/pd-dev</a><br
clear="none">
</div>
</div>
</div>
</div>
</div>
</blockquote>
</body>
</html>