Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Use <a href="http://www.kernel.org/doc/man-pages/online/pages/man3/alloca.3.html" rel="noreferrer"><code>alloca()</code></a> (sometimes called <code>_alloca()</code> or <a href="http://msdn.microsoft.com/en-us/library/5471dc8s%28v=VS.100%29.aspx" rel="noreferrer"><code>_malloca()</code></a> ), but <a href="https://stackoverflow.com/questions/1018853/why-is-alloca-not-considered-good-practice">be very careful about it</a> &mdash; it frees its memory when you leave a function, not when you go out of scope, so you'll quickly blow up if you use it inside a loop.</p> <p>For example, if you have a function like</p> <pre><code>int foo( int nDataSize, int iterations ) { for ( int i = 0; i &lt; iterations ; ++i ) { char *bytes = alloca( nDataSize ); // the memory above IS NOT FREED when we pass the brace below! } return 0; } // alloca() memory only gets freed here </code></pre> <p>Then the alloca() will allocate an <em>additional</em> nDataSize bytes <em>every time through the loop</em>. None of the alloca() bytes get freed until you return from the function. So, if you have an <code>nDataSize</code> of 1024 and an <code>iterations</code> of 8, you'll allocate 8 kilobytes before returning. If you have an <code>nDataSize</code>= 65536 and <code>iterations</code> = 32768, you'll allocate a total 65536&times;32768=2,147,483,648 bytes, almost certainly blowing your stack and causing a crash.</p> <p><strong>anecdote:</strong> You can easily get into trouble if you write past the end of the buffer, especially if you pass the buffer into another function, and that subfunction has the wrong idea about the buffer's length. <a href="http://crashworks.org/gdc11/elan_ruskin_programming_forensic_debugging.pdf" rel="noreferrer">I once fixed a rather amusing bug</a> where we were using <code>alloca()</code> to create temporary storage for rendering a TrueType font glyph before sending it over to GPU memory. Our font library didn't account for the diacritic in the Swedish &Aring; character when calculating glyph sizes, so it told us to allocate <em>n</em> bytes to store the glyph before rendering, and then actually rendered <em>n</em>+128 bytes. The extra 128 bytes wrote into the call stack, overwriting the return address and inducing a really painful nondeterministic crash!</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload