Critico frencuentemente los lenguajes inseguros respecto a la memoria, principalmente C y C++, especialmente cómo inducen un número excepcional de vulnerabilidades de seguridad. Mi conclusión, basada en la revisión de la evidencia de numerosos proyectos de software grandes que utilizan C y C++, es que debemos migrar nuestra industria a lenguajes seguros respecto al uso de la memoria (como Rust y Swift). Una de las respuestas que recibo con frecuencia es que el problema no son C y C++ en sí mismos, sino que los desarrolladores se equivocan. Desafortunadamente mi experiencia en grandes proyectos me indica que hay mucho C++ totalmente moderno que introduce vulnerabilidades.
Comentarios
C++ incluirá lifetimes y tiene más cosas interesantes que Rust. Si es que el mismo autor enlaza al debate de inclusión de lifetimes en el estándar ISO: https://github.com/isocpp/CppCoreGuidelines/issues/1038 que ya cuenta con implementaciones experimentales en MSVC y Clang
Cito textualmente: So I think that after the lengthy discussion here, this issue can now be closed. In summary: the use-after-free potential with string_view is accounted for in the Lifetime profile, even if there may be bugs or limitations in preliminary implementations that mean it is not diagnosed.
Con la especificación finalizada e implementaciones correctas no habrá problemas. Por cierto, según esa definición de lenguajes inseguros, Java tampoco es un lenguaje seguro.
#1 Y éste:
So I think we really can eliminate use-after-free/scope bugs in our C++ code today. But we have to abandon raw pointers and raw pointer wrappers like std::string_view (and span), or have the static checker treat them like scope references and impose the associated restrictions.
In practice, you're probably going to need something like registered pointers as well. The Rust language gets away without them, but they have more draconian restrictions on references, a non-trivial "borrow checker", and sometimes require the programmer to add "lifetime annotations" to their references.