EDICIóN GENERAL

[ENG] Microsoft está valorando usar Rust

The reason for this high percentage is because Windows and most other Microsoft products have been written mostly in C and C++, two "memory-unsafe" programming languages that allow developers fine-grained control of the memory addresses and where code can be executed.

¿Revisar un poco el código no podría ayudar también?
#1 En muchos casos tal vez sea mejor que los desarrolladores enfoquen su atención en cosas mucho más importantes que en detalles que no tienen que ver con el problema como por ejemplo revisar con lupa a ver si hay un desbordamiento de memoria. Un lenguaje donde sean imposibles sería más conveniente.
#4 #3 tal vez sea un idea loca, pero windows es un producto de software. A lo mejor hasta podemos "pedirle" un poco de calidad a su software.
#7 Es una idea loca, créeme.
El negocio del software no está en el desarrollo; sino en el mantenimiento. La pasta ha estado ahí de toda la vida.
#8. Como con los coches y la revisiones (y reparaciones) en los concesionarios oficiales. Al parecer el coche eléctrico necesita mucho menos mantenimiento lo que explica en parte que se haya tardado tanto en seguir los pasos de la marca Tesla.
(CC #7)
#3 No es tanto revisar despues, pero al programar cosas de sistema operativo, drivers, firmware y tal, se deberia programar con esa actitud de control por los detalles, "programacion lenta, concienzuda". Muchas mentalidades de ese tipo hacen, generalmente, que el codigo empeore. Llevo, entre una cosa y otra unos 15 años programando drivers y cosas del estilo y esa programacion lenta y de pensar y tener muy presente la memoria y el procesador y demas, esa actitud de control casi paranoico, es la que te ayuda a hacer las cosas bien, aunque tardes mas. Y ojo, empece a mirarme Rust hace un año y algun dia quiero cogerlo con ganas y tal, pero por mucho que use Rust no voy a dejar de tener esa actitud.

Por cierto, el nucleo de NT y en general lo de kernel, esta bastante pero bastante bien hecho, salvedades de pilas de drivers como WFP y demas, que ha ido cambiando y al principio siempre estan algo incompletos, pero en general NT es codigo de bastante calidad. Si que ultimamente, dicen, parece que les cuesta encontrar relevo para desarrollo de kernel, y si ha habido criticas de los dentro al resoecto, pero es mas critica al volumen y complejidad que a la calidad del codigo.
#74 De acuerdo en todo.

Sin embargo, una actitud de cuidado por los detalles de lo que se está haciendo es diferente a detalles que puede subsanar el lenguaje. Por ejemplo un lenguaje donde no se declaren las variables puede tener errores simples de tipeo que se evitarían en un lenguaje con declaración de variables. Esos son lenguajes peligrosos por mal diseño del propio lenguaje. Es estúpido hacer perder el valioso tiempo de un programador en revisar esos detalles cuando un lenguaje con declaración de variables se encuentran esos errores con cero esfuerzo del programador mientras en uno que no se declaren las variables pudiera encontrarse el problema dentro de 10 años por un hecho fortuito.

En el caso de problemas con la memoria, hacer un lenguaje más seguro puede implicar un penalti en tiempo de ejecución. Muchas veces valdrá la pena, otras veces no.
#1 Los errores de memoria son jodidos de localizar. Por ejemplo, si en una función tienes que liberar la memoria al salir, pero tienes muchos puntos de salida, es fácil que se te olvide liberarla en alguno de ellos. Y encontrar luego donde, es jodido.
#4 por eso para ese tipo de cosas se contrata a alguien que sepa y se le paga bien.
#11 Pues buena suerte con esas contrataciones, habra que tener paciencia, porque, por lo menos en este mundo, todavia no ha nacido la persona que es capaz de crear codigo totalmente libre de errores.
#11 No es ese el problema, un lenguaje de programación en muchos aspectos no deja de ser unas directrices de diseño. Si controlar manualmente la memoria es un quebradero de cabeza, y es más que probable que una persona se equivoque, pues mejor usar directrices que no incluyan ese problema.
#11 la tipica frase cuñadil sobre desarrollo de software
# #11 sí, no hay más que ver que en Google no hay tienen bugs.
#11 ¿De verdad crees que en Microsoft no hay buenos programadores y bien pagados?
#11 Microsoft tiene algunos de los mejores ingenieros del mundo, a los que paga bien y tiene entre algodones. Me quieres decir que les faltas tú o qué?
#4 Por eso una de las recomendacioones es no tener más de un punto de salida de una función, especialmente si vas a trabajar con memoria. Si la función es compleja quizás sea mejor hacer varias en vez de meterlo todo ahí. Sé que no siempre es tan sencillo como lo pintan, pero seguro que ayuda.

En cualquier caso las últimas versiones de C++ han añadido muchas ayudas al control de memoria para poder evitar y, si es necesario, localizar más fácilmente las fugas de memoria y las violaciones de acceso a memoria.
#30 #27 Err..no.
Por un lado tenemos la validacion de parametros recibidos, que cada comprobación puede ser un return en caso de error tras el seteo del error.
Por otro lado una funcion invoca a otras funciones cuyo valor devuelto puede ser un error y se debe terminar a la recepción del mismo la ejecución.
Una función con un "return" solo se ve en la Universidad. En la vida real no existen.
Antes de salir hay que liberar la memoria, o asegurarte de pasar aguas arriba el puntero a la misma (para que lo liberen cuando sea necesario).
El problema de mandarlo aguas arriba es que el programador aguas arriba debe saber que ese puntero recibido debe ser liberado y a veces son dos programadores distintos y se termina leakeando memoria (reservandola pero no liberandola...)
Pero el problema fundamental está en los buffer overflows y buffer overruns. Antiguamente existían funciones para copiar memoria de un sitio a otro, pero era responsabilidad del programador asegurarse que lo que estabas copiando "entraba" en el sitio de destino. De ahí el mítico Malloc para reservar la memoria justa. Pero claro, muchos programadores las usaban y usan incorrectamente, la cadena de origen no cabe en el hueco destino y comienza a escribir machacando datos contiguos en la memoria.
Para solventar esto, se crearon otras funciones de copia de cadenas que te obliga a decir cuantos elementos deben ser copiados. Esto obligaba a los desarrolladores a pensar en el tamaño de la copia, y se reducía el problema del overflow. O peor, el desarrollador pasaba de querer contar y usaba las funciones de copia de cadenas antiguas que no le obligaba a pasar este parámetro.
Los fallos en overflow que he visto...se cuentan por miles...y una razón es que algunas de estas funciones de copia seguras utilizan como parámetro el número de caracteres a copiar, y otras el tamaño en bytes a copiar. Cuando se utilizan cadenas tipo Char, coinciden el numero de bytes con el numero de elementos de la cadena. Pero si utilizas Wchar, el numero de bytes es el doble del numero de elementos dr la cadena.
Si utilizas una funcion de copia para copiar una cadena Wchar con 6 elementos, y resulta que pasas el numero de bytes (12) en vez del numero de caracteres (6) que utiliza el numero de caracteres como parametro....pues estás haciendo un overflow de 6.
Lo mismo pasa con las funciones de lectura, pero aqui basicamente lo que haces es un overrun...es decir...leer 12 caracteres en vez de 6. Leyendo 6 elementos de la memoria contigua que no tiene nada que ver la cadena.
O peor, hacer un underrun, si en una funcion que espera el numero de bytes a leer(12), le pasas el numero de elementos (6). Como se ha pasado 6, entiende que realmente son 6 bytes, 3 elementos. Y te deja 3 sin copiar.
Los underrun son menos peligrosos....y faciles de detectar. Pero los overflow...trackearlos son jodidos....
Ahora ya existen herramientas como Coverity que ayudan bastante en este campo.
#27 Los puntos de salida de una función no tienen nada que ver con la gestión de memoria. Es sólo un tema de legibilidad e incluso hay tendencias que están en contra, favoreciendo el early return.
#27 Es tan sencillo como usar goto a una parte final comun que libere lo que haga falta.
#4 Con alguna excepción, una función debería tener un único punto de salida.
#4 eso es así con C, con C++ y RAII eso no pasa. A parte hay herramientas como valgrind, que aunque no son la panacea, leaks de memoria como el que mencionas te los pilla.
#32 Ojo, valgrind pilla lo que se de en ejecucion, y muchos leaks, desbordes, etc. ocurren raras veces, vamos, que valgrind te pillara cosas que se reproduzcan facil, pero corner cases...
#4 Y en esos casos es donde esta justificado y recomendado usar un goto a un punto final que libera lo que haga falta.
#1 O aprender a programar en C y C++ antes de ponerse a hacer aplicaciones complejas con esos lenguajes.
#1 "Cuñao seal of approval" {0x1f3c6}

Mención especial para #26 y el resto. Gracias por participar.
#31 lo del cuñao queda bien cuando no hay muchos argumentos para contradecir un argumento. ¿donde están los tuyos?

Lo mismo nunca has estado en un proyecto de construcción de software, pero, como ya ha comentado más gente, las prioridades no suelen ser contratar gente con mucha experiencia codificando, ni aplicar metodología de medición de calidad, ni mucho menos revisar lo construido.

Ahora, gente que habla de cosas que no entiende, aquí y en los proyectos hay muchos.
#48 Decir que la gente en Microsoft no sabe programar es de un cuñadismo máximo.

Ya les gustaría a muchos listos de aquí pasar una entrevista para entrar en Microsoft ganando 150k de entrada.
#31 ¿En serio me estás diciendo que es mejor ponerse a programar en C o C++ sin saber a la hora de acometer proyectos complejos?
Yo diría que el "cuñao" aquí eres tú.
#1 ya lo revisan, no creas que le vas a enseñar a Microsoft buenas prácticas.
#37 así a primera vista parece que es mejorable el proceso
#1 También pueden actualizar un poco el código. En C++ moderno (C++11 y posteriores) hay muchísimas formas de gestionar la memoria de forma segura y eficiente.

#37 Pues, a juzgar por la calidad de algunos de sus productos, yo diría que a lo mejor sí.
#1 Y los automóviles en lugar de equiparlos con airbags y cinturones de seguridad, podriamos conducirlos con mas cuidado

menéame