path: root/devdocs/elisp/stack_002dallocated-objects.html

 <h3 class="section"> Stack-allocated Objects</h3>   <p>The garbage collector described above is used to manage data visible from Lisp programs, as well as most of the data internally used by the Lisp interpreter. Sometimes it may be useful to allocate temporary internal objects using the C stack of the interpreter. This can help performance, as stack allocation is typically faster than using heap memory to allocate and the garbage collector to free. The downside is that using such objects after they are freed results in undefined behavior, so uses should be well thought out and carefully debugged by using the <code>GC_CHECK_MARKED_OBJECTS</code> feature (see <samp>src/alloc.c</samp>). In particular, stack-allocated objects should never be made visible to user Lisp code. </p> <p>Currently, cons cells and strings can be allocated this way. This is implemented by C macros like <code>AUTO_CONS</code> and <code>AUTO_STRING</code> that define a named <code>Lisp_Object</code> with block lifetime. These objects are not freed by the garbage collector; instead, they have automatic storage duration, i.e., they are allocated like local variables and are automatically freed at the end of execution of the C block that defined the object. </p> <p>For performance reasons, stack-allocated strings are limited to <acronym>ASCII</acronym> characters, and many of these strings are immutable, i.e., calling <code>ASET</code> on them produces undefined behavior. </p><div class="_attribution">
  <p class="_attribution-p">
    Copyright &copy; 1990-1996, 1998-2022 Free Software Foundation, Inc. <br>Licensed under the GNU GPL license.<br>
    <a href="https://www.gnu.org/software/emacs/manual/html_node/elisp/Stack_002dallocated-Objects.html" class="_attribution-link">https://www.gnu.org/software/emacs/manual/html_node/elisp/Stack_002dallocated-Objects.html</a>
  </p>
</div>