Barrapunto

Por supuesto, y no lo niego, pero decir que "este" bug, especificamente, es por el goto, es de estar muy pero que muy verde en programacion.

No tengo ni idea de programación. Y no sé que hace exactamente la aplicación. Pero juraría que goto lo hace por la liberación de memoria. Es decir, no se si lo hace para ahorrarse tiempo o lo hace para otras cosas pero cualquiera que haya mirado un poco código de kernel o programas de es te tipo. El goto se utiliza muy a menudo para liberación de memoria. Es decir, dentro de la función necesitas memoria por lo tanto lo asignas. En caso de error, haces el salto a la parte donde la liberas antes de salir de la función. Recordar no hay excepciones ni recolector de memoria ni otras cosas. Por lo tanto, la forma más sencilla de hacerlo es con el goto si pusieras un return te llenarías de código de liberación de memoria.

El bug ha pasado tanto tiempo sin ser detectado por los problemas que conlleva el goto, sí. Si ese código estuviese estructurado como una cadena de if-then-elses (o incluso un if bien gordo), el bug no tendría cabida para empezar, y no sería tan difícil de detectar algo del estilo.

También lo habrían podido detectar activando los warnings de código muerto, pero eso es otro tema.

No digo que lo que esté mal sea el goto (el error es que hay uno de más), pero definitivamente la programación con gotos es lo que ha facilitado ese tipo de error, que es uno de los muchos problemas que producen los gotos. Es como si se encuentra un bug por hacer un strcpy sin comprobar el tamaño de la cadena de origen; sí, el error está en no haber comprobado el tamaño antes de llamar a strcpy, pero ese es el tipo de bugs que fomenta el uso de strcpy y el motivo por el que se desaconseja su uso.