Por que 0 <-0x80000000?

Eu tenho abaixo um programa simples:

#include <stdio.h>

#define INT32_MIN        (-0x80000000)

int main(void) 
{
    long long bal = 0;

    if(bal < INT32_MIN )
    {
        printf("Failed!!!");
    }
    else
    {
        printf("Success!!!");
    }
    return 0;
}

A condição if(bal < INT32_MIN )é sempre verdadeira. Como isso é possível?

Funciona bem se eu alterar a macro para:

#define INT32_MIN        (-2147483648L)

Alguém pode apontar o problema?

Isso é bastante sutil.

Todo literal inteiro no seu programa tem um tipo. Que tipo possui é regulado por uma tabela no 6.4.4.1:

Suffix      Decimal Constant    Octal or Hexadecimal Constant

none        int                 int
            long int            unsigned int
            long long int       long int
                                unsigned long int
                                long long int
                                unsigned long long int

Se um número literal não puder caber dentro do inttipo padrão , ele tentará o próximo tipo maior, conforme indicado na tabela acima. Portanto, para literais inteiros decimais regulares, é assim:

• Experimentar int
• Se não couber, tente long
• Se não couber, tente long long.

Literais hexadecimais se comportam de maneira diferente! Se o literal não puder caber em um tipo assinado int, ele tentará primeiro unsigned intantes de tentar tipos maiores. Veja a diferença na tabela acima.

Portanto, em um sistema de 32 bits, seu literal 0x80000000é do tipo unsigned int.

Isso significa que você pode aplicar o -operador unário no literal sem chamar o comportamento definido pela implementação, como faria ao estourar um número inteiro assinado. Em vez disso, você receberá o valor 0x80000000, um valor positivo.

bal < INT32_MINchama as conversões aritméticas usuais e o resultado da expressão 0x80000000é promovido de unsigned intpara long long. O valor 0x80000000é preservado e 0 é menor que 0x80000000, daí o resultado.

Quando você substitui o literal, 2147483648Lusa a notação decimal e, portanto, o compilador não escolhe unsigned int, mas tenta ajustá-lo dentro de a long. Além disso, o sufixo L indica que você deseja um, long se possível . O sufixo L realmente possui regras semelhantes se você continuar lendo a tabela mencionada no 6.4.4.1: se o número não couber dentro do solicitado long, o que não acontece no caso de 32 bits, o compilador lhe dará um local long longonde vai caber muito bem.

0x80000000é um unsignedliteral com o valor 2147483648.

A aplicação do menos unário nisso ainda fornece um tipo não assinado com um valor diferente de zero. (De fato, para um valor diferente de zero x, o valor com o qual você termina é UINT_MAX - x + 1).

Este literal inteiro 0x80000000tem tipo unsigned int.

De acordo com o padrão C (6.4.4.1 Constantes inteiras)

5 O tipo de uma constante inteira é o primeiro da lista correspondente na qual seu valor pode ser representado.

E essa constante inteira pode ser representada pelo tipo de unsigned int.

Então essa expressão

-0x80000000tem o mesmo unsigned inttipo. Além disso, tem o mesmo valor 0x80000000na representação do complemento dos dois que calcula da seguinte maneira

-0x80000000 = ~0x80000000 + 1 => 0x7FFFFFFF + 1 => 0x80000000

Isso tem um efeito colateral se escrever, por exemplo

int x = INT_MIN;
x = abs( x );

O resultado será novamente INT_MIN.

Assim, nesta condição

bal < INT32_MIN

é comparado 0com o valor não assinado0x80000000 convertido para o tipo long long int, de acordo com as regras das conversões aritméticas comuns.

É evidente que 0 é menor que 0x80000000.

A constante numérica 0x80000000é do tipo unsigned int. Se fizermos -0x80000000e fizermos 2s como complemento de matemática, obtemos o seguinte:

~0x80000000 = 0x7FFFFFFF
0x7FFFFFFF + 1 = 0x80000000

Então -0x80000000 == 0x80000000. E comparar (0 < 0x80000000)(já que 0x80000000não está assinado) é verdadeiro.

Um ponto de confusão ocorre ao pensar que -é parte da constante numérica.

No código abaixo 0x80000000está a constante numérica. Seu tipo é determinado apenas nisso. O -é aplicado posteriormente e não altera o tipo .

#define INT32_MIN        (-0x80000000)
long long bal = 0;
if (bal < INT32_MIN )

As constantes numéricas não adornadas não processadas são positivas.

Se for decimal, então o tipo atribuído é o primeiro tipo que vai prendê-lo: int, long, long long.

Se a constante é octal ou hexadecimal, torna-se o primeiro tipo que mantém: int, unsigned, long, unsigned long, long long, unsigned long long.

0x80000000, no sistema do OP obtém o tipo de unsignedou unsigned long. De qualquer forma, é algum tipo não assinado.

-0x80000000também é um valor diferente de zero e, sendo um tipo não assinado, é maior que 0. Quando o código compara isso a long long, os valores não são alterados nos dois lados da comparação, assim 0 < INT32_MINé verdade.

Uma definição alternativa evita esse comportamento curioso

#define INT32_MIN        (-2147483647 - 1)

Vamos caminhar na terra da fantasia por um tempo, onde inte unsignedsão de 48 bits.

Então 0x80000000se encaixa inte assim é o tipo int. -0x80000000é então um número negativo e o resultado da impressão é diferente.

[Voltar à palavra real]

Como 0x80000000se encaixa em algum tipo não assinado antes de um tipo assinado, pois é um pouco maior do que some_signed_MAXainda dentro some_unsigned_MAX, é um tipo não assinado.

C tem uma regra de que o literal inteiro pode ser signedou unsigneddepende de se encaixar signedou unsigned(promoção de número inteiro). Em uma 32máquina de bits, o literal 0x80000000será unsigned. O complemento do 2 -0x80000000está 0x80000000 em uma máquina de 32 bits. Portanto, a comparação bal < INT32_MINé entre signede unsignedantes da comparação, conforme a regra C unsigned intserá convertida em long long.

C11: 6.3.1.8/1:

[...] Caso contrário, se o tipo do operando com o tipo inteiro assinado puder representar todos os valores do tipo do operando com o tipo inteiro não assinado, o operando com o tipo inteiro não assinado será convertido no tipo do operando com tipo inteiro assinado.

Portanto, bal < INT32_MINé sempre true.