TRAPC: extensão CA para o Boogeyman de segurança da memória

No mundo das linguagens de programação, muitas vezes parece estar preso em um loop de peito do dia do puro, pois efetivamente os mesmos problemas estão sendo resolvidos repetidamente, com soluções anteriores esquecidas e sempre há que uma jubilosa inventora pateta por um porto escuro com a única solução verdadeira para tudo o que se aplica a esse mundo por que C linguagem de programação.

Como a mais recente entrada para prometer sua lealdade no altar da Igreja da Santa Memória Segurança, TRAPC promessas para consertar C, enquanto também criticou a ferrugem por permitir que isso unsafe palavra -chave. Obviamente, como este é mais um loop através do purgatório, toda a idéia de que o problema é C e algum problema percebido com essa nebulosa ‘segurança da memória’ ainda é um arenque vermelho, como apontado anteriormente.

Em outras palavras, é hora de uma viagem divertida de volta à década de 1970, quando muitos dos mesmos argumentos já estavam sendo reformulados, antes do início da década de 1980 viram os requisitos do idioma Steelman condensados ​​por especialistas de renome na linguagem de programação da ADA. Como se vê, a segurança da memória é uma parte minúscula de um programa bem escrito.

É uma armadilha

Praticamente toda a razão ZigE Kin é essa fixação em ‘segurança da memória’, com a idéia de que o problema com C é que ele não verifica os limites da memória e permite o uso de endereços de memória de maneiras que podem levar a coisas ruins. O que não quer dizer que esses eventos não sejam ruins, mas como são muito óbvios, eles também são muito fáceis de detectar ambos usando ferramentas de análise estática e dinâmica.

Como uma ‘extensão proposta em língua C’, o TRAPC acrescentaria:

• Ponteiros seguros de memória.
• Construtores e destruidores.
• o trap e alias palavras -chave.
• Informações do tipo de tempo de execução.

Também removeria:

• o goto e union palavras -chave.

The author, Robin Rowe, freely admits to this extension being ‘C++ like’, which takes us right back to 1979 when a then young Danish computer scientist (Bjarne Stroustrup) created a C-language extension cheekily called ‘C++’ to denote it as enhanced C. C++ adds many Simula features, a language which is considered the first Object-Oriented (OO) programming language and is an indirect descendant of Algol. Esses recursos do OO incluem construtores e destruidores. Juntamente com ponteiros inteligentes (opcionais) e strings e contêineres verificados por limites da biblioteca de modelos padrão (STL) C ++ é, portanto, a memória segura.

Então, qual é o sentido de remover palavras -chave como goto e union? O primeiro é praticamente a palavra -chave mais controversa da história das linguagens de programação, mesmo que deriva essencialmente diretamente dos saltos na linguagem de montagem. Na linguagem de programação da ADA, você também tem o goto Palavra-chave, com ela frequentemente usada para fornecer mais flexibilidade, onde escolhas restritivas de linguagem levariam a construções de loop complicadas, a ponto de alguns c-isss não existem em ADA, como o continue palavra -chave.

O union A palavra -chave é removida de maneira semelhante no TRAPC, com a justificativa de que as palavras -chave são “inseguras” e “amplamente depreciadas”. O que faz se perguntar quanto código C & C ++ da vida real foi analisado para chegar a essa conclusão. Em particular no campo da programação incorporada e do motorista com memória de baixo nível (e registro), acesse o uso de union é amplamente utilizado Para a flexibilidade que ele oferece.

Obviamente, se você está fazendo acesso à memória de baixo nível, também está livre para usar qualquer deslocamento do ponteiro e o tipo que você precisa, juntamente com muito inseguro, mas eficiente, memcpy() e operações semelhantes. Há uma razão pela qual o C ++ não proíbe o acesso de baixo nível sem o Guardrails, pois às vezes é necessário e espera-se que você saiba o que está fazendo. Essa liberdade na escolha entre a segurança estrita da memória e os selvagens indomados de C é uma opção de design deliberada em C ++. Na programação incorporada, você tende a compilar C ++ com RTTI e exceções desativadas também devido à sobrecarga deles.

Não chame de c ++

Efetivamente, o TRAPC adiciona RTTI, exceções (ou ‘armadilhas’), aulas de OO, ponteiros seguros e recursos de C ++ similares para C, o que levanta a questão de por que é diferente, especialmente porque o whitepaper descreve o código TRAPC e C ++ geralmente parece o mesmo que um recurso. Aqui, o idioma parece se considerar um ‘melhor C ++’, principalmente em termos de manuseio de exceções e modelos, usando ‘armadilhas’ e ‘placas de fundição’. Curiosamente, não há muito foco na “alocação de recursos é a inicialização” (RAII) que é uma pedra angular de C ++.

Enquanto isso, as placas de fundição são anunciadas como uma maneira de tornar os contêineres C ‘TypeSafe’, mas, diferentemente dos modelos de C ++, eles são criados implicitamente usando o RTTI e pode-se argumentar um pouco a sintaxe opaca (C ++, do tipo modelo). Há poucas pessoas que argumentam que o código do modelo C ++ é fácil de ler. Note aqui é que, na programação incorporada, você tende a compilar C ++ com o RTTI e as exceções desativadas devido à sobrecarga deles. A extensa dependência de RTTI no TRAPC parece impedir essa opção.

Circulando de volta à outra palavra -chave adicionada, aliasessa é a maneira da TRAPC de fornecer sobrecarga de funções e funciona como um pré -processador C #define:

void puts(void* x) alias printf("{}n",x);

Depois, há o novo trap Palavra -chave que é aparentemente importante o suficiente para ser capturada no nome da extensão. Eles são oferecidos como uma alternativa às exceções de C ++, mas a descrição é bastante confusa, além de ser supostamente menos complicada e não suporta exceções em cascata na pilha. Aqui, eu pessoalmente não vejo muito valor de qualquer maneira, como tantos desenvolvedores de C ++, detesto exceções C ++ com o fogo de mil sóis e faço o meu máximo para evitá -los.

Minha abordagem favorita aqui é encontrada em Ada, que não apenas separa de maneira limpa funções e procedimentos, mas também exige, durante o tempo de compilação, que qualquer valor de retorno de uma função é tratado e implementa exceções de uma maneira que seja leve e muito informativa, como encontrei, por exemplo, enquanto usa extensivamente o ADA array digite o contexto de um buffer de anel sem trava. Durante os testes, houve zero falhas, apenas o programa resgate com uma exceção devido a um deslocamento com defeito na matriz e listando a localização e a causa exata, como na ADA, tudo é verificado por padrão.

Segurança da memória

Grande parte da segurança no TRAPC viria de ponteiros gerenciados, com seu autor descrevendo o gerenciamento de memória da TRAPC como “automático” em um Apresentação recente em uma reunião ISO C. Os ponteiros são gerenciados pela vida, mas, como o whitepaper afirma, o método exato usado é ‘implementação definida’, em vez de contagem de referência como na especificação C ++.

No entanto, nada disso importa no contexto de questões reais de segurança. Como observei em 2024, a parte ‘Red Herring’ refere-se aos problemas de segurança da vida real que são capturados nos CVEs e sua exploração. Praticamente todos os piores CVEs envolvem a falta de validação de entrada, que permite aos usuários acessar dados em pastas ‘restritas’ e obter acesso a bancos de dados e outros recursos. Nenhum dos quais envolve a segurança da memória de qualquer forma ou, portanto, o ônus está na prevenção de erros lógicos, a validação de entrada sólida e a prevenção de programadores preguiçosos ou desatentos de introduzir o próximo CVE mundialmente famoso.

Como um programador de C&C ++ de longa data, cheguei a ‘amar’ as verrugas nesses idiomas, bem como a falta de corrimãos da liberdade que eles fornecem. Enquanto isso, aprendi a escrever casos e aproveitamentos de teste para prender meu código para sessões de controle de qualidade, porque a melhor maneira de validar o código é enfatizá -lo. Ao longo do caminho, eu me achei incrivelmente de Ada, pois seu foco na prevenção de erros de ambiguidade e lógica é evidente e regularmente me impede de cometer erros desatentos. Erros que em C ++ apareceriam no próximo teste e/ou ciclo de Valgrind, seguidos por um momento de facepalm e recompile, mas de alguma forma a programação em ADA não parece mais restritiva do que escrever em C ++.

Assim, continuarei postulando que os problemas com C já foram resolvidos em 1983 com a introdução da ADA, e aceitar esse fato é a única maneira de sair deste infinito purgatório do dia da marmota.