El sistema de plugins cada vez más cerca de GCC

Hace bastante tiempo que se viene discutiendo el porqué de la falta de sistema de plugins en el compilador libre por excelencia, GCC. Al parecer el principal problema era legal, es decir, el miedo fomentar la proliferación de plugins propietarios. Pues bien, ya se ha establecido el marco de licencias que pueden regir ese sistema, que es la nueva versión de la GCC Runtime Library Exception y con ello su desarrollo está cada vez más cerca. Además esta nueva versión de la licencia permitirá la actualización a la licencia GPLv3 de algunas librerías del propio GCC. La FSF ha proporcionado un documento con las razones para esta licencia y las preguntas más frecuentes sobre ella. Más comentarios en Slashdot: Plug-In Architecture On the Way For GCC.

Actualización: Drizzt se ha puesto de acuerdo, otra vez casualmente, para hablar del mismo tema, con algunos comentarios sobre el cambio de la licencia: El valle del Viento Helado: La arquitectura de plugins del GCC y las licencias.

La misma entrada y más comentarios en El sistema de plugins cada vez más cerca de GCC en barrapunto

Trucos gcc-céntricos y porqué no usarlos

En el estupendo blog Coding Relic el autor, Denton Gentry, ha publicado recientemente dos trucos muy espectaculares pero gcccéntricos. Bueno en realidad uno es específico de la glibc y el otro sí es una extensión de gcc:

• printf-acular en el que se describe cómo personalizar printf para que admita más tipos de datos que los que normalmente admite, en el ejemplo sacar direcciones MAC formateadas.
• Variable Scoping with gcc, en el que se explica el (espectacular) funcionamiento de __attribute__(cleanup), que permite funcionalidades del tipo RAII de C++

Y ahora, después de ver un par de extensiones tan útiles, potentes y elegantes es cuando me toca desrecomendarlas :) Creo firmemente en el valor de los estándares y en desarrollar siempre en el nivel más estricto de estándar o visto de otro modo en el nivel más amplio de disponibilidad, siempre y cuando las soluciones sean comparables. Además, es bueno pensar en la gente que retocará el código y cabe la posibilidad de que si no se documenta resulte de sólo escritura. Yo sólo lo vería admisible en un hack puntual documentado como mínimo con neones. No obstante, hay gente que no opina lo mismo como se puede leer en Uso de extensiones del GCC en (el kernel) Linux.


La misma entrada y más comentarios en Trucos gcc-céntricos y porqué no usarlos en barrapunto

La ley de Postel y los programadores

El otro día leí un comentario acerca de las diferencias en la admisión de parámetros entre los comandos en BSD y GNU. Según se comentaba, los segundos son menos estrictos y se tragan más cosas. El comentarista añadía sobre el comportamiento de la GNU userland: "me gusta a pesar del programador que hay en mi".

Y, por lo que sea, me ha parecido muy revelador: a los programadores no nos gusta, desde un punto de vista egoísta, lo que nos supone la ley de Postel, el principio de robustez. Aquello de ser liberal con lo que se admite como válido da repelús. Y creo que hay más de un motivo:

• Nos gusta la precisión. Si somos estrictos en lo que generamos ¿No vamos a exigir lo mismo?
• Se suele generar más código para tener el cuenta el ser liberal: más trabajo y más testeo
• El comportamiento de nuestro soft no es tan rígido lo que choca con nuestro gusto por las especificaciones precisas, sencillas y breves.

Lo que a veces no vemos es que ser menos estricto mejora la robustez y eso al usuario final, como es normal, le encanta aunque le de igual si se es estricto, si Postel o Dracón, los estándares y todo lo demás.

Este efecto se nota más en ecosistemas heterogéneos con lo que la integración de ese software puede ser más fácil en entornos menos controlados. Así que otra cosa más a pensar antes de desarrollar ¿Nos compensará a la larga el esfuerzo de ser menos estrictos?

La misma entrada y más comentarios en La ley de Postel y los programadores en barrapunto