Cosa è ":-!!" nel codice C?

Ho incontrato questo strano codice macro in /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); }))

Cosa fa :-!!?

Questo è, in effetti, un modo per verificare se l'espressione e può essere valutata come 0 e, in caso contrario, per fallire la compilazione .

La macro è in qualche modo erroneamente denominata; dovrebbe essere qualcosa di più simile BUILD_BUG_OR_ZERO, piuttosto che ...ON_ZERO. (Ci sono state discussioni occasionali sul fatto che si tratti di un nome confuso .)

Dovresti leggere l'espressione in questo modo:

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

1. (e): Calcola espressione e.

2. !!(e): Nega logicamente due volte: 0se e == 0; altrimenti 1.

3. -!!(e): Annulla numericamente l'espressione dal passaggio 2: 0se lo era 0; altrimenti -1.

4. struct{int: -!!(0);} --> struct{int: 0;}: Se era zero, allora dichiariamo uno struct con un bitfield intero anonimo con larghezza zero. Va tutto bene e procediamo normalmente.

5. struct{int: -!!(1);} --> struct{int: -1;}: D'altra parte, se non è zero, sarà un numero negativo. Dichiarare qualsiasi campo di bit con larghezza negativa è un errore di compilazione.

Quindi finiremo con un bitfield che ha larghezza 0 in una struttura, il che va bene, o un bitfield con larghezza negativa, che è un errore di compilazione. Quindi prendiamo sizeofquel campo, quindi otteniamo un size_tcon la larghezza appropriata (che sarà zero nel caso in cui esia zero).

Alcune persone hanno chiesto: perché non usare solo un assert?

La risposta di keithmo qui ha una buona risposta:

Queste macro implementano un test di compilazione, mentre assert () è un test di runtime.

Completamente giusto. Non vuoi rilevare problemi nel tuo kernel in fase di esecuzione che potrebbero essere stati rilevati in precedenza! È un elemento critico del sistema operativo. In qualunque misura i problemi possano essere rilevati in fase di compilazione, tanto meglio.

Il :è un campo di bit. Per quanto riguarda !!, questa è la doppia negazione logica e quindi ritorna 0per falso o 1per vero. E -c'è un segno meno, cioè una negazione aritmetica.

È solo un trucco per ottenere il compilatore su input non validi.

Prendere in considerazione BUILD_BUG_ON_ZERO. Quando -!!(e)restituisce un valore negativo, viene generato un errore di compilazione. Altrimenti -!!(e)restituisce 0 e un campo di bit con larghezza 0 ha una dimensione di 0. E quindi la macro restituisce un size_tvalore con 0.

Il nome è debole dal mio punto di vista perché la build in realtà fallisce quando l'input non è zero.

BUILD_BUG_ON_NULLè molto simile, ma produce un puntatore anziché un int.

Alcune persone sembrano confondere queste macro con assert().

Queste macro implementano un test in fase di compilazione, mentre assert()è un test di runtime.

Bene, sono abbastanza sorpreso che le alternative a questa sintassi non siano state menzionate. Un altro meccanismo comune (ma meno recente) è chiamare una funzione non definita e fare affidamento sull'ottimizzatore per compilare la chiamata di funzione se la tua affermazione è corretta.

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

Mentre questo meccanismo funziona (fintanto che le ottimizzazioni sono abilitate) ha il rovescio della medaglia di non segnalare un errore fino al collegamento, a quel punto non riesce a trovare la definizione per la funzione you_did_something_bad (). Ecco perché gli sviluppatori del kernel iniziano a usare trucchi come le larghezze di campo bit di dimensioni negative e le matrici di dimensioni negative (la parte successiva ha smesso di interrompere le build in GCC 4.4).

In sintonia con la necessità di asserzioni in fase di compilazione, GCC 4.3 ha introdotto l' errorattributo della funzione che consente di estendere questo concetto precedente, ma di generare un errore in fase di compilazione con un messaggio di propria scelta - non più "criptico" array di dimensioni negative " messaggio di errore!

#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)

In effetti, a partire da Linux 3.9, ora abbiamo una macro chiamata compiletime_assertche utilizza questa funzionalità e la maggior parte delle macro inbug.h sono state aggiornate di conseguenza. Tuttavia, questa macro non può essere utilizzata come inizializzatore. Tuttavia, usando le espressioni statement (un'altra estensione C di GCC), puoi!

#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;                                                    \
    })

Questa macro valuterà il suo parametro esattamente una volta (nel caso abbia effetti collaterali) e creerà un errore di compilazione che dice "Ti ho detto di non darmi un cinque!" se l'espressione restituisce cinque o non è una costante di compilazione.

Quindi perché non stiamo usando questo invece di campi bit di dimensioni negative? Purtroppo, al momento ci sono molte restrizioni all'uso delle espressioni delle istruzioni, incluso il loro uso come inizializzatori costanti (per costanti di enum, larghezza del campo di bit, ecc.) Anche se l'espressione dell'istruzione è completamente costante il suo sé (cioè, può essere valutato completamente in fase di compilazione e in caso contrario supera il __builtin_constant_p()test). Inoltre, non possono essere utilizzati al di fuori di un corpo di funzione.

Eventualmente, GCC modificherà presto queste carenze e consentirà di utilizzare espressioni di istruzioni costanti come inizializzatori costanti. La sfida qui è la specifica del linguaggio che definisce ciò che è un'espressione costante legale. C ++ 11 ha aggiunto la parola chiave constexpr proprio per questo tipo o cosa, ma non esiste alcuna controparte in C11. Mentre C11 ha ottenuto affermazioni statiche, che risolveranno parte di questo problema, non risolverà tutte queste carenze. Quindi spero che gcc possa rendere disponibile una funzionalità constexpr come estensione tramite -std = gnuc99 & -std = gnuc11 o alcuni di questi e consentirne l'uso su espressioni di istruzioni et. al.

Sta creando un 0campo di dimensioni se la condizione è falsa, ma un campo di dimensioni -1( -!!1) se la condizione è vera / diversa da zero. Nel primo caso, non si verificano errori e la struttura viene inizializzata con un membro int. In quest'ultimo caso, c'è un errore di compilazione (e -1ovviamente non viene creato un bitfield di dimensione ).