<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Memory Allocation Y GC Desde Cero on Void *Pablogs</title><link>https://pablogs.dev/es/series/memory-allocation-y-gc-desde-cero/</link><description>Recent content in Memory Allocation Y GC Desde Cero on Void *Pablogs</description><generator>Hugo</generator><language>es</language><lastBuildDate>Sun, 24 May 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://pablogs.dev/es/series/memory-allocation-y-gc-desde-cero/index.xml" rel="self" type="application/rss+xml"/><item><title>Lo que malloc() no quiere que sepas</title><link>https://pablogs.dev/es/posts/post-01-no-malloc/</link><pubDate>Sun, 24 May 2026 00:00:00 +0000</pubDate><guid>https://pablogs.dev/es/posts/post-01-no-malloc/</guid><description>&lt;p&gt;&lt;em&gt;Post 1 de 13 — Serie: Memory Allocation y Garbage Collection desde cero&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;Cada vez que escribes &lt;code&gt;malloc(128)&lt;/code&gt;, ocurre algo aparentemente mágico: el runtime te devuelve un puntero a 128 bytes de memoria que nadie más está usando. No pediste permiso al sistema operativo. No especificaste &lt;em&gt;dónde&lt;/em&gt; querían vivir esos bytes. Simplemente aparecieron. Y cuando llamas &lt;code&gt;free()&lt;/code&gt;, desaparecen de vuelta al vacío.&lt;/p&gt;
&lt;p&gt;La magia es mentira.&lt;/p&gt;
&lt;p&gt;Debajo de &lt;code&gt;malloc()&lt;/code&gt; no hay nada sofisticado. Hay una syscall que mueve un número hacia arriba. Hay un puntero que avanza. Hay una estructura de datos que lleva la cuenta. Tu programa, cualquier programa en C, está corriendo código muy parecido al que vamos a escribir hoy.&lt;/p&gt;</description></item></channel></rss>