O que é ":-!!" no código C?

Eu encontrei esse código de macro estranho em /usr/include/linux/kernel.h :

/* Force a compilation error if condition is true, but also produce a
   result (of value 0 and type size_t), so the expression can be used
   e.g. in a structure initializer (or where-ever else comma expressions
   aren't permitted). */
#define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:-!!(e); }))
#define BUILD_BUG_ON_NULL(e) ((void *)sizeof(struct { int:-!!(e); }))

O que :-!!faz?

Esta é, com efeito, uma maneira de verificar se a expressão e pode ser avaliada como 0 e, se não, falhar na construção .

A macro é um pouco errada; deveria ser algo mais parecido BUILD_BUG_OR_ZERO, ao invés de ...ON_ZERO. (Houve discussões ocasionais sobre se esse é um nome confuso .)

Você deve ler a expressão assim:

sizeof(struct { int: -!!(e); }))

1. (e): Computar expressão e.

2. !!(e): Negar logicamente duas vezes: 0se e == 0; caso contrário 1.

3. -!!(e): Negue numericamente a expressão da etapa 2: 0se foi 0; caso contrário -1.

4. struct{int: -!!(0);} --> struct{int: 0;}: Se fosse zero, declaramos uma estrutura com um campo de bits inteiro anônimo que possui largura zero. Está tudo bem e prosseguimos normalmente.

5. struct{int: -!!(1);} --> struct{int: -1;}: Por outro lado, se não for zero, será um número negativo. Declarar qualquer campo de bits com largura negativa é um erro de compilação.

Portanto, terminaremos com um campo de bits que possui largura 0 em uma estrutura, o que é bom ou um campo de bits com largura negativa, que é um erro de compilação. Em seguida, pegamos sizeofesse campo e obtemos um size_tcom a largura apropriada (que será zero no caso em que eé zero).

Algumas pessoas perguntaram: Por que não usar apenas um assert?

A resposta de keithmo aqui tem uma boa resposta:

Essas macros implementam um teste em tempo de compilação, enquanto assert () é um teste em tempo de execução.

Exatamente certo. Você não deseja detectar problemas no seu kernel em tempo de execução que poderiam ter sido detectados anteriormente! É uma parte crítica do sistema operacional. Em qualquer extensão, os problemas podem ser detectados em tempo de compilação, tanto melhor.

O :é um campo de bits. Quanto a !!, isso é dupla negação lógica e, portanto, retorna 0para falso ou 1verdadeiro. E o -é um sinal de menos, ou seja, negação aritmética.

É apenas um truque para fazer com que o compilador vomite em entradas inválidas.

Considere BUILD_BUG_ON_ZERO. Quando -!!(e)avalia para um valor negativo, isso produz um erro de compilação. Caso contrário, será -!!(e)avaliado como 0, e um campo de bits com largura 0 terá tamanho 0 e, portanto, a macro será avaliada como a size_tcom valor 0.

O nome é fraco, na minha opinião, porque a construção falha de fato quando a entrada não é zero.

BUILD_BUG_ON_NULLé muito semelhante, mas gera um ponteiro em vez de um int.

Algumas pessoas parecem estar confundindo essas macros assert().

Essas macros implementam um teste em tempo de compilação, enquanto assert()é um teste em tempo de execução.

Bem, estou surpreso que as alternativas a essa sintaxe não tenham sido mencionadas. Outro mecanismo comum (mas mais antigo) é chamar uma função que não está definida e confiar no otimizador para compilar a chamada de função se sua afirmação estiver correta.

#define MY_COMPILETIME_ASSERT(test)              \
    do {                                         \
        extern void you_did_something_bad(void); \
        if (!(test))                             \
            you_did_something_bad(void);         \
    } while (0)

Embora esse mecanismo funcione (desde que as otimizações estejam ativadas), ele tem a desvantagem de não relatar um erro até você vincular, quando não consegue encontrar a definição para a função you_did_something_bad (). É por isso que os desenvolvedores do kernel começam a usar truques, como as larguras de campo de bits de tamanho negativo e as matrizes de tamanho negativo (o último dos quais parou de quebrar as compilações no GCC 4.4).

Simpatizando com a necessidade de asserções em tempo de compilação, o GCC 4.3 introduziu o erroratributo function que permite estender esse conceito mais antigo, mas gera um erro em tempo de compilação com uma mensagem de sua escolha - não mais uma matriz de tamanho negativo "enigmática" " mensagens de erro!

#define MAKE_SURE_THIS_IS_FIVE(number)                          \
    do {                                                        \
        extern void this_isnt_five(void) __attribute__((error(  \
                "I asked for five and you gave me " #number))); \
        if ((number) != 5)                                      \
            this_isnt_five();                                   \
    } while (0)

De fato, a partir do Linux 3.9, agora temos uma macro chamada compiletime_assertque usa esse recurso e a maioria das macros bug.hforam atualizadas de acordo. Ainda assim, essa macro não pode ser usada como inicializador. No entanto, usando expressões de declaração (outra extensão C do GCC), você pode!

#define ANY_NUMBER_BUT_FIVE(number)                           \
    ({                                                        \
        typeof(number) n = (number);                          \
        extern void this_number_is_five(void) __attribute__(( \
                error("I told you not to give me a five!"))); \
        if (n == 5)                                           \
            this_number_is_five();                            \
        n;                                                    \
    })

Essa macro avaliará seu parâmetro exatamente uma vez (caso tenha efeitos colaterais) e criará um erro em tempo de compilação que diz "Eu disse para você não me dar cinco!" se a expressão for avaliada como cinco ou não for uma constante em tempo de compilação.

Então, por que não estamos usando isso em vez de campos de bits de tamanho negativo? Infelizmente, atualmente existem muitas restrições ao uso de expressões de instrução, incluindo o uso como inicializadores constantes (para constantes enum, largura de campo de bits etc.), mesmo que a expressão de instrução seja completamente constante, ela própria (ou seja, pode ser totalmente avaliada em tempo de compilação e passa no __builtin_constant_p()teste). Além disso, eles não podem ser usados ​​fora de um corpo funcional.

Felizmente, o GCC alterará essas deficiências em breve e permitirá que expressões constantes de instruções sejam usadas como inicializadores constantes. O desafio aqui é a especificação da linguagem que define o que é uma expressão constante legal. O C ++ 11 adicionou a palavra-chave constexpr apenas para esse tipo ou coisa, mas nenhuma contrapartida existe no C11. Embora o C11 tenha obtido afirmações estáticas, o que resolverá parte desse problema, ele não resolverá todas essas deficiências. Então, espero que o gcc possa disponibilizar uma funcionalidade constexpr como uma extensão via -std = gnuc99 & -std = gnuc11 ou algo parecido e permitir seu uso nas expressões de declaração et. al.

Ele está criando um campo de 0bits de tamanho se a condição for falsa, mas um campo de bit de tamanho -1( -!!1) se a condição for verdadeira / diferente de zero. No primeiro caso, não há erro e a estrutura é inicializada com um membro int. No último caso, há um erro de compilação (e -1, naturalmente , não existe um campo de bits de tamanho ).