
20 de junio de 2026
3 min lectura
Linux acaba de eliminar la función strncpy tras 360 parches y seis años. Lo que esta limpieza de código revela sobre la calidad del software que usas cada día.
Tras seis años de trabajo y 360 parches, el kernel de Linux ha eliminado por completo la función strncpy de su código. No es una simple limpieza: es la eliminación de una fuente histórica de bugs de seguridad y mantenimiento que afectaba al sistema operativo más usado del planeta — desde servidores hasta tu Android.
strncpy era una función de la biblioteca estándar de C diseñada para copiar cadenas de texto de forma segura. En teoría. En la práctica, su comportamiento confuso (no añade un terminador nulo si la cadena origen es demasiado larga) ha causado incontables vulnerabilidades de desbordamiento de búfer y fugas de memoria. Cada parche eliminado representa un punto potencial de fallo que ya no existe.
Para el usuario final, esto significa kernels más estables y seguros sin tener que hacer nada. Pero para desarrolladores y equipos de producto, la lección es más profunda: el código heredado — por muy estándar que sea — puede y debe ser reemplazado cuando su diseño es defectuoso. Linux no se conformó con parchear los síntomas; reescribió el tejido mismo.
strncpy fue sustituida por alternativas más seguras como strscpy y , diseñadas específicamente para el kernel.strtomemSi eres desarrollador: audita tu propio código en busca de strncpy y funciones similares con comportamientos ambiguos. Sustitúyelas por alternativas explícitas y seguras. No esperes a que un parche de seguridad te obligue.
Si eres responsable de producto: programa auditorías de deuda técnica como parte del ciclo de desarrollo. Dedicar tiempo a limpiar código viejo no es lujo; es prevención de incidentes futuros.
Si eres usuario: actualiza tu kernel. Las distribuciones Linux ya están incorporando estos cambios en sus versiones estables. Un simple sudo apt upgrade o equivalente te protege de años de bugs potenciales.
“Linux eliminó 360 puntos de fallo potencial tras seis años de trabajo: la calidad del software no se improvisa, se construye con decisiones incómodas y sostenidas.