Inteiros em complemento de dois com apenas o bit de sinal definido devem ser uma representação armadilha
Tratar o menor valor inteiro de complemento de dois (o padrão com apenas o bit de sinal definido, por exemplo INT_MIN) como uma armadilha ou sentinela semelhante a NaN poderia tornar overflow de inteiros e inteiros opcionais mais seguros e fáceis de lidar, mas quebraria o código existente e exigiria suporte de hardware ou compilador. Os comentários ponderam o apelo de intervalos simétricos e valores embutidos para “ausente” contra as realidades de desempenho, interoperabilidade FFI e décadas de software que assumem aritmética simples de wrap. Muitos argumentam que melhores ferramentas (sanitizers, bigints explícitos ou novos tipos inteiros com valores “niche” reservados) são preferíveis a redefinir a semântica central de inteiros em C, C++ e ISAs comuns.
Proposta e Motivação
- A discussão gira em torno de tornar o valor de complemento de dois “com apenas o bit de sinal” (por exemplo, INT_MIN) um caso especial:
- Ou uma representação armadilha (usá-lo causa uma falha/exceção).
- Ou um sentinela semelhante a NaN usado para inteiros “ausentes”/inválidos.
- Motivações discutidas:
- Intervalos inteiros simétricos (−N..+N em vez de −N−1..+N).
- Representações mais baratas de
optional<int>/ inteiros anuláveis usando esse padrão de bits. - Eliminar casos extremos como o overflow de
abs(INT_MIN)em C.
Hardware, Desempenho e Implementação
- Muitos argumentam que isso só realmente faz sentido com suporte de hardware; verificações em software após cada operação são vistas como caras demais para linguagens de baixo nível.
- Outros apontam que linguagens dinâmicas ou de alto nível (Python, Lisp, Swift, R) já pagam custos semelhantes (bignums, verificações de limites, sentinelas).
- DSPs e algumas ISAs suportam modos alternativos de aritmética (aritmética com saturação, flags de overflow), que poderiam ser aproveitados em vez disso.
Correção, UB e Semântica da Linguagem
- Debate intenso sobre overflow assinado em C/C++ ser indefinido:
- Alguns querem wrap (
-fwrapv) ou traps (-ftrapv) como padrões. - Outros enfatizam que depender de UB para otimização criou bugs reais de segurança e comportamentos difíceis de depurar.
- Alguns querem wrap (
- Fez-se a distinção entre:
- Uma representação armadilha (apenas ler/escrever isso é UB em C).
- Um valor semelhante a NaN com semântica de propagação definida.
- Vários observam que adaptar isso retroativamente ao C quebraria código existente, hoje correto, e expectativas de FFI.
Alternativas: Bignums, Saturação, Sentinelas
- Alternativas discutidas:
- Inteiros de precisão arbitrária como padrão (Lisp, Scheme, Python).
- Tipos de faixa/intervalo em que valores fora da faixa codificam “ausente”.
- Instruções ou operações de biblioteca com aritmética saturada.
- Tipos de nicho no nível da linguagem ou biblioteca (não zero, ints de 63 bits, otimização de “niche” do Rust, ints marcados do OCaml, inteiro NA do R).
Segurança vs Disponibilidade
- Alguns preferem falhar/travar no overflow para evitar corrupção silenciosa de dados.
- Outros, especialmente em domínios de segurança ou missão crítica, priorizam continuar operando mesmo com valores errados em vez de encerrar o processo.
- Consenso: o comportamento desejável depende muito do domínio; um único padrão de hardware ou linguagem não satisfará todos os casos de uso.