Inteiros não são o que você acha que são
Você vai escrever uma função simples de cálculo de desconto e descobrir que ela retorna valores negativos quando o preço ultrapassa certo limite. Isso acontece todo dia. O problema com números inteiros não é conceitualmente difícil, mas as armadilhas aparecem em lugares que você não espera. Vou explicar primeiro o que geralmente dá errado na prática, depois entro nos detalhes técnicos. A maioria dos devs aprende isso depois de passar horas debugando algo que deveria ser trivial.
O que realmente acontece com problemas com números inteiros
Inteiros em programação têm um tamanho fixo. Um int de 32 bits armazena valores de -2.147.483.648 a 2.147.483.647. Quando você faz uma operação que ultrapassa esse teto, o valor "vaza" para o lado negativo. Isso se chama overflow com sinal. Em algumas linguagens o comportamento é definido pela especificação, em outras é indefinido — e undef behavior é onde bugs difíceis nascem. Eu passei duas semanas rastreando um bug em um sistema de faturamento onde o total mensal de uma conta de luz simplesmente ficava negativo. A causa? Uma soma acumulada de centavos convertida para inteiros sem preservar a casa decimal, multiplicada por um fator de correção que extrapolaria o limiar do INT32. O código parecia inofensivo: era basicamente um loop de soma.
👉 Clique no botão abaixo para saber mais sobre o assunto!
O workaround foi simples mas custoso: trocar o tipo base de cálculo para INT64 em toda a cadeia de processamento e validar o range antes de qualquer operação aritmética. Demorou cerca de três dias de testes porque o mesmo problema aparecia em pelo menos onze módulos diferentes. A lição é que overflow de inteiros raramente fica isolado num único ponto do sistema. A regra prática mais importante: sempre defina o tipo de inteiro antes de escrever a lógica, não depois. Escolher INT32 quando o domínio exige valores maiores é o erro mais comum que eu vejo em code review.
Operações que parecem seguras mas não são
Multiplicações encadeadas são as grandes vilãs. Duas variáveis INT32 aparentemente inocentes, cada uma com valor de 50.000, produzem 2.500.000.000 — acima do limite. O resultado estoura para negativo e sua validação posterior nunca detecta porque o dano já aconteceu antes da checagem. Divisão inteira também causa confusão. Em Python, -7 // 3 retorna -3, não -2 como alguns esperariam. Isso é truncamento para menos infinito, diferente de C/Java que truncam para zero. Se seu código precisa rodar em múltiplas plataformas, esse detalhe quebra lógica de arredondamento de forma consistente e silenciosa.
Outro ponto: conversão implícita entre tipos. Em linguagens com tipagem fraca ou coerção automática, atribuir um float grande a uma variável inteira pode truncar sem aviso. Em C, casting de unsigned para signed com valor acima do max produz comportamento indefinido no padrão C99. Em Rust, você ganha um panic em debug e wrap-around em release. Cada linguagem trata isso de um jeito. Eu recomendo evitar castings implícitos completamente. Use conversões explícitas com validação de range. Existe uma biblioteca chamada num em Rust e Math.BigInteger em Java que ajudam, mas elas mudam a performance — operações com BigInt são significativamente mais lentas que com inteiros nativos, especialmente em loopsApresentação curta de Agnes
