… está (tão) preocupado assim com os problemas de segurança, relacionados com a memória RAM! Sabendo que ela está perdendo o seu espaço para as linguagens de programação “memory safety”, de já ter perdido há tempos a coroa de linguagem mais popular do mercado e de quebra, ser boicotada pelas agências de segurança, era de se esperar que o comitê responsável pela linguagem em questão, tomasse medidas e/ou providências para solucionar os seus problemas & limitações. Mas por incrível que pareça, parece isto não irá acontecer tão cedo…
“Memory safety isn’t a top priority for the ISO C++ 26 standard, despite growing concerns that it is a black hole in the programming language. Frustrated committee members said that conflicting interests, differing priorities and lack of participation has stymied the passing of memory safety proposals. The topic was discussed during a technical session at the Supercomputing 2024 (SC2024) conference, held recently in Atlanta.”
— by The New Stack.
Segundo Bruno Lopes, engenheiro de software na Meta (que também é membro do comitê de padrões C++), declarou que “não está muito confiante de que haverá um cronograma razoável para isso”, já que no momento a segurança não é o maior foco, em vista das outras prioridades (estabelecidas pelos próprios participantes). Já Gonzalo Brito (arquiteto de GPUs da Nvidia), isto se dá em vista do fato de que muitos participantes presentes nas reuniões não são especialistas na área e por isto, ele não espera nenhuma melhoria neste quesito, mesmo ciente de que eles considerem a segurança algo importante para ser levado em conta.
Na prática, eles estão mais preocupados em resolver os seus problemas do que realmente cuidar da linguagem de programação: “o que me importa é poder depurar programas em escala ou não deixá-los falhar”, disse Brito. Para variar, outros participantes que estão em prol das propostas para a segurança de memória em C++, estão entrando em conflito com aqueles que “não estão nem aí” para estes problemas. Inclusive, eles apresentaram várias propostas para resolver e/ou mitigar tais problemas relacionados a segurança, como o uso de compiladores que trazem os mesmos recursos usados em Rust e a implementação de profiles (de Bjarne Stroustrup) para realizar notas de códigos, fazer suposições e por fim, estabelecer requisitos de segurança para construir e compilar programas.
Embora elas tenham sido apresentadas para atacar o problema “sob vários ângulos”, Lopes acredita que vai levar um certo tempo para que todas elas possam convergir para uma determinada direção e por isto, ele não está tão esperançoso de que tais planejamentos serão de fato, executados (em um curto espaço de tempo). Para variar, programadores que usam linguagens alternativas com ênfase na segurança de memória, também têm enormes bases de código C e C++ pré-existentes, o que acaba trazendo mais complicações à médio e longo prazo. Por fim, até mesmo têm sido feitas tentativas de aproximação com a comunidade Rust, para que eles possam promover uma melhor interoperabilidade entre ambas as linguagens e no processo, buscar soluções que visam resolver os problemas em questão.
Enquanto isto, algumas empresas de Tecnologia já estão substituindo códigos escritos em C++ para Rush, como é o caso da Microsoft para as aplicações do sistema operacional, designadas para lidar com a sua inicialização (o firmware UEFI é escrito em Rush, além do código que suporta o chip de segurança Pluton). Já o Google, há tempos que a empresa já vem divulgando as pesquisas que tem feito sobre o assunto e que sob o ponto de vista dela, “colocam as indústrias e a sociedade em perigo”. Por fim, até mesmo a DARPA (Defense Advanced Research Projects Agency) já está promovendo o TRACTOR (Translating All C to Rust), um tradutor capaz de converter códigos de programas legados escritos em C/C++ para Rust.
Ou as linguagens C/C++ se reformulam ou elas terão um triste fim… &;-D