Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions docs/Chapters/01-memory.html
Original file line number Diff line number Diff line change
Expand Up @@ -485,7 +485,7 @@ <h3 data-number="3.1.5" class="anchored" data-anchor-id="sec-heap"><span class="
<blockquote class="blockquote">
<p>Unlike stack memory, heap memory is allocated explicitly by programmers and it won’t be deallocated until it is explicitly freed <span class="citation" data-cites="jenny2022">(<a href="../references.html#ref-jenny2022" role="doc-biblioref">Chen and Guo 2022</a>)</span>.</p>
</blockquote>
<p>To store an object in the heap, you, the programmer, needs to explicitly tells Zig to do so, by using an allocator to allocate some space in the heap. In <a href="#sec-allocators" class="quarto-xref"><span>Section 3.3</span></a>, I will present how you can use allocators to allocate memory in Zig.</p>
<p>To store an object in the heap, you, the programmer, needs to explicitly tell Zig to do so, by using an allocator to allocate some space in the heap. In <a href="#sec-allocators" class="quarto-xref"><span>Section 3.3</span></a>, I will present how you can use allocators to allocate memory in Zig.</p>
<div class="callout callout-style-default callout-important callout-titled">
<div class="callout-header d-flex align-content-center">
<div class="callout-icon-container">
Expand Down Expand Up @@ -517,7 +517,7 @@ <h3 data-number="3.1.6" class="anchored" data-anchor-id="summary"><span class="h
<h2 data-number="3.2" class="anchored" data-anchor-id="sec-stack-overflow"><span class="header-section-number">3.2</span> Stack overflows</h2>
<p>Allocating memory on the stack is generally faster than allocating it on the heap. But this better performance comes with many restrictions. We have already discussed many of these restrictions of the stack in <a href="#sec-stack" class="quarto-xref"><span>Section 3.1.4</span></a>. But there is one more important limitation that I want to talk about, which is the size of the stack itself.</p>
<p>The stack is limited in size. This size varies from computer to computer, and it depends on a lot of things (the computer architecture, the operating system, etc.). Nevertheless, this size is usually not that big. This is why we normally use the stack to store only temporary and small objects in memory.</p>
<p>In essence, if you try to make an allocation on the stack, that is so big that exceeds the stack size limit, a <em>stack overflow</em> happens, and your program just crashes as a result of that. In other words, a stack overflow happens when you attempt to use more space than is available on the stack.</p>
<p>In essence, if you try to make an allocation on the stack, that is so big that it exceeds the stack size limit, a <em>stack overflow</em> happens, and your program just crashes as a result of that. In other words, a stack overflow happens when you attempt to use more space than is available on the stack.</p>
<p>This type of problem is very similar to a <em>buffer overflow</em>, i.e., you are trying to use more space than is available in the “buffer object”. However, a stack overflow always causes your program to crash, while a buffer overflow does not always cause your program to crash (although it often does).</p>
<p>You can see an example of a stack overflow in the example below. We are trying to allocate a very big array of <code>u64</code> values on the stack. You can see below that this program does not run successfully, because it crashed with a “segmentation fault” error message.</p>
<div class="cell">
Expand Down Expand Up @@ -1306,4 +1306,4 @@ <h3 data-number="3.3.9" class="anchored" data-anchor-id="the-create-and-destroy-



</body></html>
</body></html>