La seguridad de memoria suele presentarse como un concepto difuso y polémico, pero la realidad es más sencilla: puede entenderse como un espectro y, al mismo tiempo, admitir una definición práctica que no depende de tecnicismos. El código verdaderamente seguro es aquel cuyas reglas sobre la memoria son intuitivas y fáciles de seguir, salvo que haya una señal explícita que indique lo contrario —el equivalente a una valla que delimita lo seguro de lo inseguro. Esta idea, bautizada por el autor como la "ley del agua no flotante", resulta clave para usuarios reales que no diseñan modelos de memoria ni compiladores.
El ensayo parte de la reciente propuesta de Zig de adoptar un modo de compilación inspirado en Fil-C, descrito como una implementación de C con seguridad de memoria. El autor desmonta la afirmación mostrando con un ejemplo en C cómo un strcpy sobre una estructura puede sobrescribir un campo adyacente y elevar privilegios sin disparar errores en tiempo de ejecución, porque Fil-C solo atrapa accesos fuera de la asignación, no las escrituras dentro de ella. Esa clase de "trampas sin marcar" invalida, en la práctica, el reclamo de seguridad total y contrasta con el modelo de Rust, donde las operaciones inseguras están delimitadas por bloques explícitos (unsafe). El texto ilustra además otros casos —Python con CFFI, Rust escribiendo en /proc/self/mem— para mostrar que un lenguaje puede seguir siendo seguro aun permitiendo FFI, siempre que estas puertas estén claramente señalizadas. La conclusión es clara: la seguridad de memoria existe para que el programador no tenga que preocuparse por la máquina abstracta, y etiquetar como "seguro" cualquier sistema con trampas ocultas trivializa el concepto.