En el mundo del desarrollo de software, las vulnerabilidades de memoria siguen siendo una de las principales amenazas para la seguridad informática. A pesar de los avances en la creación de lenguajes de programación más seguros, gran parte del software crítico aún depende de tecnologías con décadas de antigüedad, como C y C++.
|
etiquetas: vulnerabilidades , c , c++ , industria , eeuu 
Ya, que solo usas el stack. Como los años 80.
```
* MyStruct bang() {
MyStruct ms[5];
* MyStruct result = &ms[4];
result ++;
return result;
}
```
Me sorprendería si el analizador estático puede detectar eso.
2. Ese código ni siquiera compila.
3. En el caso de que fuera sintácticamente correcto, es bastante probable que un analizador estático sea capaz de detectar el problema.
Pero eso no significa que solo puedas usar memoria de la pila. Tienes make_unique / make_shared que reservan de forma segura memoria heap y que liberan la memoria cuando ya no se necesita. Y por supuesto, todos los contenedores de la biblioteca estándar y de boost.
Respecto a tu ejemplo, cualquier analizador estático de medio pelo detecta ese error. Clang-tidy lo hace.
Si quieres exprimir el rendimiento de algo, es fácil que tengas que hacer "guarradas", y lo pongo entre comillas porque no creo que realmente estén bien o mal, simplemente son fuentes de problemas, pero lo considero malo en sí mismo.
Esto me recuerda a que supuestamente los chinos sacan mayor rendimiento a las tarjetas de nvidia porque pasan de su API.
Suena parecido, pero no lo es
También el hardware cada vez es más potente y los compiladores más inteligentes (o por lo menos pueden probar diferentes métodos de optimización mucho más rápido que una persona y detectar cual es más rápido), así que al igual que ya no compensa programar… » ver todo el comentario
No te darás cuenta, pero hay montones de código en ensamblador para acelerar ciertos algoritmos usando todos los recursos de las CPUs populares. Por ejemplo, ejecutar expresiones regulares, compresión, hashing, cifrado, cálculos matemáticos avanzados… busca un poco y verás que el ensamblador sigue ofreciendo una ventaja entre el 500% y el 10000%.
Incluso si utilizas Python o Java, por debajo hay decenas de miles de líneas de ensamblador para optimizar los algoritmos críticos.
Como ejemplo de que algo parecía buena idea en su día, pero resultó no serlo tanto me gusta el emulador zsnes, programado íntegramente en ensamblador. En su día era lo mejor porque era rapidísimo y su… » ver todo el comentario
Los señoros de la Casa Blanca no sé qué clase de asesores tendrán, pero vaya tela...
Pero el problema no es solo los memory leak, sino los accesos a memoria. En C++ puedes desbordar un array sin consecuencias, pudiendo acceder a basura o... Contenido de otra parte de la memoria. Y debido a eso, muchos proyectos han tenido agujeros de seguridad gigantescos.
Es algo con lo que se debe tener cuidado, si.
Eso es una referencia circular. Si usas shared pointers con una referencia circular, vas a tener un memory leak.
ChatGPT te puede generar un código para que lo simules si quieres.
Es una lata poner código por aquí pero si con un print en los constructores y otro en los destructores se puede demostrar. Te he encontrado un ejemplo en stackoverflow:
stackoverflow.com/questions/77322229/how-do-unique-ptrs-prevent-the-cy
Yo creo que muchos programadores han invertido tiempo y esfuerzo en aprender un lenguaje mastodontico y ahora no quieren tirar por la borda ese dinero/esfuerzo. Y como ya he dicho, tambien estan los projectos ya hechos en c/c++ que hay que mantenerlos... Para mi c/c++ es el nuevo cobol...
eluaproject.net/
Que es en lua. La idea es querer. No se trata de que c/c++ sea mejor, se usa por inercia y comodidad. No hay nada inerente en el lenguaje c/c++ que lo haga especial para microcontroladores, solo que es lo que se ha usado siempre...
En C lo tiene que hacer el programador.
Yo trabajé programando en C una red neuronal (hace 25 años, antes de que se pusiera de moda), la diferencia entre hacerlo en C o C++ era abismal (probamos otros lenguajes, pero nada podía competir con C). Optimizamos las multiplicaciones de matrices y la gestión de memoria todo lo posible, pero lo que dio mejor resultado fue cambiar la gestión de multitarea del propio Linux, quitándole todas las protecciones para que fuera mucho más rápido, conseguimos que el entrenamiento pasara de 2 meses a 2 semanas.
Los shared pointers tienen un pequeño impacto porque tienen que realizar el conteo de referencias cada vez que se crean o destruyen, pero los unique pointers son gratis, no afectan al rendimiento para nada.
Fuera de liberar la memoria. Tampoco soluconan el desbordamiento en vectores/arrays.
Estar pendiente de si necesitas shared_ppinter o weak_ptr es una fuente de errores. Es mucho menos propenso a errores tener un garbage collector que solucione esto por ti.
Si intentas escribir pasado el final de un std::vector o std::array tienes una bonita excepción si activas el address sanitizer (-fsanitize=address tanto en g++ como en clang).
Además clang-tidy detecta muchos de esos casos antes de mezclar el cambio en el repositorio Git.
Yo siempre he mantenido que Rust en todo caso puede suplir a C, pero no a C++
Lo único que le veo yo es que puedes usarlo con menos restricciones, lo que lo hace preferible para videojuegos, pero Rust da mayor seguridad, lo que lo hace preferible para OS y cosas críiticas.
Estos aun no se enteraron de Cobol en los bancos jjj
Luego ves que necesitas un popurrí de tecnologías de diferentes compañías para conseguir lo mismo, pero cada una con su ciclo de deprecación, sus licencias e incompatibilidades que sobre el papel no sale a cuenta.
Copilot no sé si es compatible, pero generar rutinas de cobol a golpe de prompt sería otra nueva juventud para este vetusto lenguaje.
Hace un año.
¿Por qué genbeta saca un artículo ahora, qué ha ocurrido?
Portada en MNM.
Punteros sin inicializar, asignación a variables de cadenas sin comprobar la longitud y conversión de tipos de datos inseguros.
Creo que ademas ya hay lo que dices, creo que se llamaba SONAR