LinuxParty

El núcleo de Linux se está moviendo a C moderno. Interesante artículo en LWN.net que se hace eco de informaciones en la lista de correos de los responsable del Kernel de Linux y su decisión de modernizar el lenguaje C que usan, que sigue siendo el de la versión de ¡¡1989!! lo que podría finalizar con la versión 5.18 del kernel, que se espera para mayo de este año.

La discusión comenzó con las inquietudes de uno de los responsables de mantenimiento del kernel, Jakob Koschel, relacionado con las vulnerabilidades provocadas en las listas vinculadas, que se basan en structs anidados que usan un iterador para recorrer la lista y que puede aprovechar una vulnerabilidad para acceder a la struct superior, lo que es potencialmente peligroso. Koschel expuso que la razón principal era la imposibilidad de declarar variable en bucles, como se puede hacer en la versión C99, no la C89 que sigue usando el kernel de Linux.

Linus Torvalds acabó apoyando la idea, sugiriendo que "había llegado el momento de cambiar al estándar C99". Arnd Bergmann, encargado de vigilar los problemas de los compiladores entre arquitecturas, estuvo de acuerdo en que debería ser posible que el kernel escale. Incluso sugirió que sería posible llegar hasta el estándar C11, origen del C moderno. Después de que Bergmann confirmara que debería ser posible hacerlo, Torvalds declaró : " Ok, alguien, por favor, recuérdamelo, y probemos esto temprano en la ventana de fusión 5.18 ". Falta menos de un mes para la ventana de fusión 5.18, por lo que este es un cambio que podría ocurrir en un futuro cercano.

Sin embargo, vale la pena tener en cuenta que pueden suceder muchas cosas entre la ventana de combinación y la versión 5.18. Pasar a una nueva versión del lenguaje estándar podría revelar una serie de sorpresas en lugares oscuros del núcleo; no se necesitarían muchos de ellos para revertir el cambio por ahora. Pero, si todo va bien, el cambio a C11 ocurrirá en la próxima versión del kernel. Sin embargo, parece probable que la conversión de todos los usuarios de list_for_each_entry() y variantes (de las cuales hay más de 15 000 en el kernel) a una nueva versión que no exponga el iterador interno lleve un poco más de tiempo.