El primer paso es abrir el archivo, y mirar en la cabecera. Los programadores de software libre suelen indicar en la cabecera del c\u00f3digo qui\u00e9n es el autor. Por ejemplo, si tomamos un programa al azar, como pueda ser este<\/a>, vemos que el autor lo tenemos en la cabecera:<\/p>\n (Est\u00e1 marcado con un circulo y unas flechitas por si alg\u00fan chaval de 20 a\u00f1os o alg\u00fan blogero influyente de la A-list tienen problemas en encontrarlo).<\/p>\n Bueno, ya sabemos el autor al que debemos achacar el problema. Pero esto no tiene importancia, porque acabamos de encontrar un posible problema de seguridad que nos parece grav\u00edsimo. Lo adecuado aqu\u00ed es recordar que el CVS es una instant\u00e1nea en el pasado de un proyecto, y que el problema puede ya estar solucionado. Seguimos con la imagen:<\/p>\n (Est\u00e1 marcado con un circulo y unas flechitas por si alg\u00fan chaval de 20 a\u00f1os o alg\u00fan blogero de la A-list tienen problemas en encontrarlo. Para ellos va tambi\u00e9n la explicaci\u00f3n de lo que es un CVS, por si lo desconocen).<\/p>\n Bueno, esto parece que tiene cinco a\u00f1os… Y nadie parece haber tocado el c\u00f3digo en cuatro a\u00f1os… o el proyecto est\u00e1 muerto hace cuatro a\u00f1os, o ya nadie usa ese CVS. \u00bfQue hacemos? Preguntar al mantenedor cual es la versi\u00f3n m\u00e1s reciente. Si no, podemos estar dando un parte de seguridad de un error que puede que fuera corregido hace tres a\u00f1os, y que el CVS no lo utilice nadie desde hace cuatro a\u00f1os<\/strong>. Especialmente si es un proyecto cuya historia desconocemos y no nos hemos tomado la molestia de informarnos.<\/p>\n Supongamos que con la emoci\u00f3n de un chaval de 20 a\u00f1os que ha encontrado un error de seguridad en un paquete con una complejidad que no entiende, queremos dar un parte de seguridad por el problema. \u00bfQue hacemos?<\/p>\n Ni\u00f1os, vamos a aprender un concepto clave: como se dan los partes de posibles vulnerabilidades.<\/strong><\/p>\n La gracia est\u00e1 en el orden<\/b> de los pasos. \u00bfPorqu\u00e9? Porque lo primero en estas cosas no es el ego; sino la ventana de vulnerabilidad que se crea dando la noticia antes de que haya parche, y que pueda ser alegremente explotada. En software privativo solo podr\u00edamos avisar de los s\u00edntomas. En software libre tenemos la ventaja competitiva de que podemos arreglar los problemas en cuanto los detectamos. Si somos buenos ciudadanos del ecosistema de software libre podemos aportar la soluci\u00f3n al momento.<\/p>\n \u00bfComo no se hacen las cosas? Pues al rev\u00e9s; primero lo notificas en meneame, un d\u00eda m\u00e1s tarde, lo mandas a bugtraq, donde un blogger de la A-list -que participaba en la discusi\u00f3n de meneame- se hace eco del problema. Y al mantenedor del paquete \u00bfpara que avisarlo? Que se joda, es uno de los imb\u00e9ciles que desarrolla software libre. Si cae alg\u00fan sistema por la vulnerabilidad en su c\u00f3digo, mejor, uno menos de estos cabrones del software libre. M\u00e1s carne para que muerda el blogger. <\/strong><\/p>\n Todo esto le puede pasar a un hipot\u00e9tico chaval de 20 a\u00f1os que no lleve suficiente tiempo en esto del software como para saber que los avisos de seguridad se hacen as\u00ed por algo. Lo peor que puede pasar es que nuestro chaval de 20 a\u00f1os sea un lince, y haya descubierto un error: miles de sistemas vulnerables durante una noche. Da\u00f1os econ\u00f3micos cuantiosos. P\u00e9rdida de datos. Cuando el mantenedor del paquete de software libre se despierte al d\u00eda siguiente, ser\u00e1 demasiado tarde. Objetivo cumplido.<\/p>\n Pero lo mejor que suele ocurrir es precisamente lo que es normal, cuando estas cosas las hace un hipot\u00e9tico chaval de 20 a\u00f1os calentado por un blogger de la A-list. Especialmente si no est\u00e1 claro como explotar la vulnerabilidad, y apenas realiza una b\u00fasqueda con grep de las funciones en C que todos sabemos que potencialmente puedan tener problemas de seguridad. Si hubiese contactado con el desarrollador de software libre a cargo del paquete -cuyo tel\u00e9fono movil est\u00e1 en su web- se habr\u00eda enterado que:<\/p>\n Si hubiese contactado primero con el mantenedor del paquete, cosa que se puede hacer en software libre y no en el privativo, el chaval de 20 a\u00f1os habr\u00eda aprendido un mont\u00f3n de cosas. Adem\u00e1s, probablemente hubiese recibido una felicitaci\u00f3n por parte del desarrollador de software libre -promete mucho con su edad y siendo capaz de llegar a ese punto, por identificar un problema potencial y saber gestionar la crisis-. Hubiese ganado un amigo. De esas redes de contactos va el software libre. No ha dado una falsa alarma -ya que la rama mayormente usada de ese paquete no tiene el problema-. Incluso el desarrollador le hubiese ayudado a rellenar la entrada en los canales de notificaci\u00f3n respecto a la otra rama de c\u00f3digo, para evitar que el chaval cometa alg\u00fan error conceptual:<\/p>\n El error potencialmente es un buffer overflow de una aplicaci\u00f3n local, que no toca red, no es servidor, no abre un socket; por lo que no deber\u00edas marcarlo como explotable remotamente. Adem\u00e1s, por no consultar puede ocurrir que te saquen los colores en la propia lista de seguridad<\/a>. Por cierto, nixpanic -el que le saca los colores a nuestro chaval- no es alumno ni empleado m\u00edo. Este es su perfil en linkedit<\/a>. Se dedica a desarrollar drivers para linux.<\/p>\n Pero a lo que \u00edbamos: puede ocurrir que, despu\u00e9s de analizar el c\u00f3digo, encuentres algo que te parezca extra\u00f1o. No err\u00f3neo, sino extra\u00f1o:<\/p>\n (bueno, esto est\u00e1 escrito por el blogger influyente de la A-list… S\u00ed, para \u00e9l, poner un punto y coma de m\u00e1s es un error grave, y la tabulaci\u00f3n muy grave)<\/p>\n Cualquier desarrollador con experiencia en sistemas grandes y complejos sabe que muchas veces encuentras \u201clegacy code\u00bb con caracter\u00edsticas raras. Para cualquier persona con experiencia real en ingenier\u00eda inversa -en el caso del que escribe estas l\u00edneas, que gan\u00e9 dicha experiencia leyendo tochos en Fortran de programas de f\u00edsica computacional hechos por el director de tesis de mi director de tesis, hace eones y sin documentaci\u00f3n-, sabe que las cosas extra\u00f1as que aparecen en el c\u00f3digo suelen ser soluciones ad-hoc a bugs muy dif\u00edciles de localizar.<\/strong><\/p>\n \u00bfLa soluci\u00f3n? Enfundarse el ego, localizar al autor, y preguntarle el porqu\u00e9 de una l\u00ednea.<\/p>\n Su contestaci\u00f3n puede ser una sarta de absurdidades -en cuyo caso, ya sabemos que no sabe C-, o comentarnos el porqu\u00e9 del problema. Conociendo la forma de ser de los desarrolladores, probablemente incluso tengamos que aguantar una batallita de como localiz\u00f3 el error. Es el problema de la gente que disfruta con su trabajo.<\/p>\n En este caso particular, el problema estaba en el optimizador del gcc<\/strong>. En la versi\u00f3n del compilador que empleaba en la \u00e9poca, hab\u00eda reportes de errores que estaban causados porque con O3 el compilador se empe\u00f1aba en ejecutar la funci\u00f3n Bueno, parece que de este c\u00f3digo que hemos analizado desde el principio no hemos sacado nada. En parte, porque era un programa muy grande, en el que mucha gente meti\u00f3 mano. Tambi\u00e9n porque el mantenedor ha dicho numerosas veces en p\u00fablico que gran parte del c\u00f3digo est\u00e1 heredado de MOSIX, que este c\u00f3digo ten\u00eda este tipo de problemas y que estaba saj\u00e1ndolo de errores<\/strong>. Quiz\u00e1s deb\u00edamos haber ido a por la versi\u00f3n desarrollada por nuestro objetivo. Vamos a tomar c\u00f3digo de un proyecto que solamente \u00e9l haya metido mano.<\/p>\n Encontramos una joyita: un programa de casi 18000 l\u00edneas de c\u00f3digo escrito en dos lenguajes -C importando con Entramos en el c\u00f3digo, y vemos algo raro. Dejando a un lado que parte del programa est\u00e1 en C, y se incluye con Hacemos:<\/p>\n Evidentemente, no vamos a morder como un d\u00f3berman aqu\u00ed, reclamando que esto es un error. Primero, porque no lo es: el programa es correcto. Podemos reclamar que esto es una guarrada, y que es un programador guarrete. Pero el hecho de que los punteros se puedan referenciar much\u00edsimo m\u00e1s legible y c\u00f3modamente de otra forma, y que lo normal es que la persona con limitados conocimientos en programaci\u00f3n desconozca precisamente la forma de operar con los punteros que emplea nuestro objetivo, deber\u00eda llamarnos la atenci\u00f3n. No es que programe como si desconociera la aritm\u00e9tica de punteros, sino que emplea la aritm\u00e9tica de punteros de forma pedante e inusual, mucho m\u00e1s compleja de lo que parece necesario<\/strong>. Probablemente, como en el caso anterior, nos estamos perdiendo algo.<\/p>\n Como somos profesionales serios, contactamos con el desarrollador. Su contestaci\u00f3n puede ser una sarta de absurdidades -en cuyo caso, ya sabemos que no sabe C-, o comentarnos el porqu\u00e9 del problema.<\/p>\n El problema est\u00e1 en lo que no tenemos: los requisitos. El programador nos cuenta que hay programas de software como OsiriX que tienen un soporte completo a ficheros en formato DICOM, pero que la plataforma sobre la que se ejecutan es muy cara -Mac OS X-. Que comenz\u00f3 siendo una pr\u00e1ctica del programa de doctorado; pero que se encontr\u00f3 con la sorpresa de que tuvo una ingente cantidad de descargas, y correos de agradecimiento: el programa estaba siendo usado en regiones con escasos recursos en Sudam\u00e9rica y \u00c1frica. Una pr\u00e1ctica de doctorado se acababa de convertir en algo con utilidad social. La reclamaci\u00f3n que todo el mundo hac\u00eda es que era demasiado lento. Por ello, la soluci\u00f3n fue reescribir el c\u00f3digo del renderizador de DICOM; de tal forma que fuese muy eficiente en m\u00e1quinas antiguas. El autor del programa puede que ya fuese perro viejo optimizando programas de c\u00e1lculo num\u00e9rico, por lo que ten\u00eda trucos en la rec\u00e1mara. Y este era uno de ellos.<\/strong><\/p>\n Supongamos que no nos fiamos y desconocemos los rudimentos de la optimizaci\u00f3n en este tipo de programas. En ese caso, pedimos pruebas de que esto es as\u00ed. Al desarrollador de software libre hasta le hace gracia que se lo pidamos -puesto que es un cl\u00e1sico de las optimizaciones-, y nos manda un c\u00f3digo en C:<\/p>\n for (;j<60000000;j+=2)psaux++;<\/p>\n printf(\"%d\",psaux); Lo compilamos -como nos dice- con C\u00d3DIGO RESTO PROGRAMA con c\u00f3digo optimizado con C\u00d3DIGO RESTO PROGRAMA Si compilamos sin optimizar. En m\u00e1quinas de 32 bits, el compilador genera un Aqu\u00ed podemos avisarle que est\u00e1 incrementando una variable que ya no utiliza. Probablemente nos lo agradezca, diga que se utilizaba para algo entre los Nos faltaba, pues, conocer los requisitos: una vez conocidos, podemos discutir la priorizaci\u00f3n de eficiencia sobre legibilidad, o el hecho de liberar c\u00f3digo sin pasar el comando indent sobre \u00e9l. Pero podemos darnos una idea de que es un programador pragm\u00e1tico y con recursos.<\/strong><\/p>\n Evidentemente, esto puede pasar en tambi\u00e9n otros aspectos del programa: como el hecho de que nuestro programador emplee Bueno, la verdad es que esto son solamente algunas l\u00edneas gen\u00e9ricas sobre como hacer bien un \u201cshow me the code\u00bb si queremos una impresi\u00f3n real y objetiva de c\u00f3mo es un programador. Pero lo m\u00e1s importante es lo que comentamos al principio: olvidar los prejuicios. Pero si buscamos una nube con forma de cerdito, terminaremos encontr\u00e1ndola.<\/p>\n Finalmente, si nuestra intenci\u00f3n no es esa, sino utilizar nuestro poder para transmitir mensajes y movilizar con un objetivo: atacar a un desarrollador de software libre comprometido, con m\u00e1s de un centenar de miles de l\u00edneas de c\u00f3digo liberadas en varios proyectos estrat\u00e9gicos para la comunidad, la mejor gu\u00eda os la puede dar un blogger de la A-list aqu\u00ed<\/a>.<\/strong> Despu\u00e9s de ejecutada, aunque el ego del blogger A-list sea un poquito mayor, y estar\u00e1 un poquito m\u00e1s tranquilo de que nadie en la comunidad del software libre se atrever\u00e1 en el futuro a no re\u00edrle las gracias, habr\u00e1 creado un peligroso precedente sobre la relaci\u00f3n que debe tener un desarrollador de software libre con su c\u00f3digo liberado, y ha abierto el camino para que los desarrolladores de software libre tengamos alguna preocupaci\u00f3n m\u00e1s que no tienen los de software privativo. Es muy f\u00e1cil tomar un programa que ahora ya va por m\u00e1s de 30000 l\u00edneas de c\u00f3digo en su \u00faltima versi\u00f3n, sacar media docena de l\u00edneas de contexto y, desconociendo completamente porqu\u00e9 se ha optado por ello, atacarle personalmente.<\/strong> No es posible estar justificando cada docena de l\u00edneas que te descontextualizan en un texto de 20000 caracteres . Simplemente, no todos tenemos el tiempo de estar defendi\u00e9ndonos de gente con ganas de tumbar a personas y proyectos.<\/p>\n Un mensaje final para el blogger de la A-list: Si no te gusta mi c\u00f3digo, m\u00e1ndame un parche para arreglar lo que no te guste<\/strong>. Se constructivo.<\/p>\n Si te sent\u00edas ofendido personalmente, sigue sin ser justificable. Literalmente, dije: \u201cPorque antes entrar\u00e1 Chikilicuatre que un Ingeniero en Inform\u00e1tica en la Comisi\u00f3n Interministerial de la Sociedad de la Informaci\u00f3n y de las Nuevas Tecnolog\u00edas en Espa\u00f1a. Y siempre habr\u00e1 un Ricardo que dir\u00e1 que aprendi\u00f3 m\u00e1s inform\u00e1tica afin\u00e1ndole la guitarra a Chikilicuatre que en cinco a\u00f1os de Ingenier\u00eda Inform\u00e1tica.\u00bb, t\u00fa con tu gran capacidad de comprensi\u00f3n lectora entiendes que te he llamado ingeniero de Chiquilicuate<\/strong>. Fuistes t\u00fa el que has dicho en tu blog, en la entrada que te contesto, todo lo que no has aprendido dentro de la carrera. Yo me he limitado a se\u00f1alar que lo que tu dices que no aprendistes en tu universidad privada, yo s\u00ed lo he estudiado en una universidad p\u00fablica andaluza, donde he recibido una formaci\u00f3n de nivel<\/strong>. De hecho, comento mi convencimiento de que estas cosas se estudian en Argentina. Un gran cient\u00edfico como tu deber\u00eda ser capaz de entender un texto como este, y entrar en una discusi\u00f3n constructiva. Por cierto, respondes insistentemente lo de que todos te atacamos v\u00eda \u201cad-hominem\ufffd?. Pero debes tener en cuenta que eres t\u00fa el que emplea, como \u00fanico argumento en cualquier discusi\u00f3n, la gran autoridad que tienes como gran figura \u201cblogger chachi\u00bb\/\u201cgur\u00fa software libre\u00bb\/\u201cgran empresario-t\u00e9cnico meneame\u00bb\/\u201ccient\u00edfico con cuarenta publicaciones\u00bb. Y cualquier discusi\u00f3n de tus argumentos, como se centran en t\u00ed, en tus dichos, tu sabidur\u00eda y tus an\u00e9cdotas sobre t\u00ed, terminan toc\u00e1ndote. Es m\u00e1s sencillo declarar en la blogosfera: no tomar\u00e1s en nombre de Gallir en vano.<\/strong><\/p>\n Te respeto como persona -como a todas las personas-. Respeto tu aportaci\u00f3n al software libre -como respeto a todos los que colaboran: haciendo contribuciones tan alucinantes como la tuya, tan miserables como la m\u00eda-. De hecho, a m\u00ed me parecen respetables todas las contribuciones, aunque sea traduciendo tres l\u00edneas de un fichero de configuraci\u00f3n. A t\u00ed, veo que no. Defiendo el respeto a los desarrolladores de software libre, como ya los defiende toda la comunidad. <\/p>\n Otra cosa es que t\u00fa y yo tengamos una discusi\u00f3n sobre un tema concreto. En este caso, sobre el nivel formativo de los estudios de Ingenier\u00eda en Inform\u00e1tica, y sobre si un Colegio de Ingenieros en Inform\u00e1tica es bueno o no para la sociedad -colegio que en muchas autonom\u00edas espa\u00f1olas ya es una realidad legal-. Pero discrepamos sobre una opini\u00f3n manifestada en una entrada a tu blog: Entrada en la que t\u00fa mismo dices de tu propia boca lo poco que aprendiste estudiando tu carrera<\/strong>; no lo digo yo, lo has dicho t\u00fa mismo. Me he limitado a repetir lo que t\u00fa dices, y a\u00f1adir que yo s\u00ed que lo he estudiado en mi universidad, y que estoy muy orgulloso de haber estudiado Ingenier\u00eda Inform\u00e1tica en una universidad p\u00fablica de mi tierra. <\/p>\n Por mucho que discutamos, aunque me insultes -que yo no creo que te haya insultado- no te voy a hacer un show me the code como el que tu me has hecho. Si alg\u00fan d\u00eda te audito tu c\u00f3digo, te va a llegar un parche por correo electr\u00f3nico, corrigiendo tus errores.<\/strong> Esa es la diferencia entre la critica destructiva y la constructiva. El problema no es que hayas mostrado mis verg\u00fcenzas, sino que no eran tales. El problema es que termina siendo mi capacidad de dar credibilidad contra la tuya, frente a gente que puede no entender los listados de c\u00f3digo. Es un problema de popularidad, no un problema de buen c\u00f3digo.<\/strong> El problema es que no tengo trabajo asegurado de por vida; soy un profesional de la Ingenier\u00eda Inform\u00e1tica, lo que no me permite quedarme imp\u00e1vido. Por otro lado no tengo todo el tiempo del mundo para hacer siete p\u00e1ginas de explicaci\u00f3n cada vez que alguien como t\u00fa decide que saca doce l\u00edneas de contexto y me pone a parir. Si quieres hacerlo, estupendo. Es un pa\u00eds libre. Pero luego no tengas la poqu\u00edsima verg\u00fcenza de erigirte en palad\u00edn del software libre y speaker de la FSF para pontificar sobre lo divino y lo humano, cuando para cualquier persona con dos dedos de luces es aterradora la idea de que una persona con tu capacidad de difusi\u00f3n de informaci\u00f3n pueda hacer este tipo de cosas.<\/strong><\/p>\n Hace una semana pensaba que Ricardo Galli tiraba piedras contra el tejado de la Ingenier\u00eda Inform\u00e1tica. Ahora creo que las tira contra la Ingenier\u00eda Inform\u00e1tica, contra mi profesi\u00f3n, y adem\u00e1s contra el software libre<\/strong>. No porque yo sea el software libre, sino porque los m\u00e9todos de Ricardo para asegurar que nadie ose discutirle las opiniones son da\u00f1inos para todos. Pero igual que cuando las tiras contra el tejado de mi profesi\u00f3n la gente se ha revelado, y no tienes credibilidad entre los Ingenieros en Inform\u00e1tica, con actitudes como esta quemas tu credibilidad como autoproclamado palad\u00edn del software libre.<\/p>\n Tags:ciencia<\/a>, legales<\/a>, software libre<\/a>, \u00e9tica<\/a>,colegios inform\u00e1ticos<\/a>, David Santo Orcero<\/a>, Ricardo Galli<\/a>,deontolog\u00ed\u00ada<\/a>, programaci\u00f3n b\u00e1sica<\/a>.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":" La idea de hacer un buen \u201cshow me the code\u00bb no es del todo mala: ver el c\u00f3digo fuente de un proyecto te permite descubrir si puede dar problemas a la hora de mantenerlo; as\u00ed como si va a tener … Continue reading ![](\"http:\/\/www.orcero.org\/irbis\/showmethecode1.jpg\")
<\/p>\n![](\"http:\/\/www.orcero.org\/irbis\/showmethecode2.jpg\")
<\/p>\n\n
![](\"http:\/\/www.orcero.org\/irbis\/showmethecode3.jpg\")
<\/p>\n\n
![](\"http:\/\/www.orcero.org\/irbis\/showmethecode4.jpg\")
<\/p>\n![](\"http:\/\/www.orcero.org\/irbis\/showmethecode5.jpg\")
<\/p>\nip_need_two_phase<\/code>, funci\u00f3n que generaba efectos laterales. Seg\u00fan el est\u00e1ndar de C, if(a&&b)<\/code> deber\u00eda ser equivalente a if(a)if(b)<\/code>. Esto no deber\u00eda ocurrir, pero ocurr\u00eda. Un error dif\u00edcil de localizar; pero, una vez localizado, el arreglo era trivial y el c\u00f3digo arreglado se ve est\u00fapido. El problema lleva a\u00f1os corregido en el gcc. Pero el c\u00f3digo as\u00ed desarrollado es correcto -quiz\u00e1s feo- pero funciona perfectamente en compiladores con y sin el problema.<\/strong> <\/p>\nextern C<\/code> y C++- en su versi\u00f3n 0.6, sobre el que la persona objetivo reclama la autor\u00eda completa<\/strong>. Falta apenas una cosa que no obtendremos: la documentaci\u00f3n del an\u00e1lisis y los requisitos. Esto puede ser un problema; porque es dif\u00edcil evaluar quien corre mejor o m\u00e1s r\u00e1pido si nadie sabe cual es la meta. Pero bueno, hay cosas que se pueden verificar sin eso.<\/p>\nextern C<\/code>, y parte est\u00e1 en C++. El autor en numerosos puntos del programa en lugar de sumar una cantidad prefijada a un puntero, lo incrementa varias veces. Para que hasta el blogger prestigioso e influyente de la A-list o el chaval de 20 a\u00f1os puedan entenderlo, es como si en lugar de hacer:<\/p>\n
\n4+3=7
\n<\/code><\/p>\n
\n4+1+1+1=7
\n<\/code><\/p>\n
\nvoid main()
\n{
\nchar *psaux=0;
\nlong int j=0;<\/p>\n
\n}
\n<\/code><\/p>\n-S<\/code> y empleando -march<\/code> para forzar c\u00f3digo para una plataforma antigua -un athlon mismo nos vale-, y obtenemos algo como:<\/p>\n
\n.L10:
\n cmpl $59999999, %eax
\n jle .L3<\/p>\n
\n.L3:
\n incl %ecx
\n addl $2, %eax
\n jmp .L10
\n<\/code><\/p>\n-O2<\/code>, y:<\/p>\n
\n.L10:
\n cmpl $59999999, %eax
\n jle .L3<\/p>\n
\n.L3:
\n incl -12(%ebp)
\n addl $2, %eax
\n jmp .L10
\n<\/code><\/p>\nincl DESPLAZAMIENTO(%ebp)<\/code>, y optimizando -que es la opci\u00f3n por defecto en kradview-, genera un incl %REGISTRO<\/code>. Entonces sabemos que nuestra v\u00edctima del show me the code ten\u00eda raz\u00f3n: incrementar el puntero es incrementar un registro; mientras que sumar un n\u00famero supone leer al menos un entero de 32 bits de memoria, meterlo en registro y sumarle uno. Aunque en una m\u00e1quina moderna la velocidad es similar, en una m\u00e1quina que ya tenga algunos a\u00f1os la diferencia de velocidades es abismal. Una optimizaci\u00f3n guarrilla, pero que funciona.<\/strong><\/p>\npaux++<\/code> antiguamente, pero que el c\u00f3digo se retir\u00f3; pero tambi\u00e9n puede que nos diga que llegamos tarde, y que faltaban un par de d\u00edas para liberar la pr\u00f3xima versi\u00f3n de la aplicaci\u00f3n. En la versi\u00f3n nueva, de m\u00e1s de 30000 l\u00edneas de c\u00f3digo, sigue haci\u00e9ndose esta optimizaci\u00f3n con punteros. Pero esa variable ya no est\u00e1.<\/p>\nflush<\/code> en algunos lugares elegidos; cuando emplear setlinebuf()<\/code> llamada una sola vez al principio del programa es un castigo muy grande para el rendimiento en m\u00e1quinas antiguas: el objetivo no es poner el stream como unbuffered siempre, sino solamente cuando es imprescindible<\/strong>. O haya alg\u00fan archivo al que al programador se le hubiera olvidado pasar el indent<\/code> para ajustar las tabulaciones -para el blogger: es un programa que genera autom\u00e1ticamente las indentaciones correctas-. Evidentemente, ni mencionaremos como cr\u00edtica que sea algo pedante escribiendo c\u00f3digo, poniendo siempre punto y coma despu\u00e9s delif<\/code> para asegurarse que no se despistar\u00e1 con los else<\/code>, o que ponga par\u00e9ntesis de m\u00e1s -cosas que no afectan al rendimiento, pero s\u00ed a la legibilidad, mejor\u00e1ndola-: al fin y al cabo son cosas que mejoran la legibilidad sin tener coste de rendimiento, y no vamos a reclamar a un programador por ello.<\/strong><\/p>\n