Algunas personas parecen estar confundiendo estas macros con assert() .
Estas macros implementan una prueba en tiempo de compilación, mientras que assert() es una prueba de tiempo de ejecución.
Esta es, en efecto, una forma de verificar si la expresión e puede evaluarse como 0 y, de no ser así, fallar la compilación .
La macro tiene un nombre algo incorrecto; debería ser algo más como BUILD_BUG_OR_ZERO , en lugar de ...ON_ZERO . (Ha habido discusiones ocasionales sobre si este es un nombre confuso .)
Deberías leer la expresión así:
sizeof(struct { int: -!!(e); }))
-
(e):Calcular la expresióne. -
!!(e):lógicamente niega dos veces:0sie == 0; de lo contrario1. -
-!!(e):niega numéricamente la expresión del paso 2:0si fuera0; de lo contrario-1. -
struct{int: -!!(0);} --> struct{int: 0;}:Si fuera cero, entonces declaramos una estructura con un campo de bits entero anónimo que tiene ancho cero. Todo está bien y procedemos con normalidad. -
struct{int: -!!(1);} --> struct{int: -1;}:Por otro lado, si no es cero, entonces será un número negativo. Declarar cualquier campo de bits con negativo ancho es un error de compilación.
Entonces terminaremos con un campo de bits que tiene un ancho de 0 en una estructura, lo cual está bien, o un campo de bits con un ancho negativo, que es un error de compilación. Luego tomamos sizeof ese campo, por lo que obtenemos un size_t con el ancho adecuado (que será cero en el caso de que e es cero).
Algunas personas han preguntado:¿Por qué no usar simplemente un assert? ?
La respuesta de Keithmo aquí tiene una buena respuesta:
Estas macros implementan una prueba en tiempo de compilación, mientras que assert() es una prueba en tiempo de ejecución.
Exactamente correcto. No desea detectar problemas en su kernel en tiempo de ejecución que podría haber sido capturado antes! Es una pieza crítica del sistema operativo. En la medida en que se puedan detectar problemas en tiempo de compilación, tanto mejor.
Bueno, estoy bastante sorprendido de que no se hayan mencionado las alternativas a esta sintaxis. Otro mecanismo común (pero más antiguo) es llamar a una función que no está definida y confiar en el optimizador para compilar la llamada a la función si su afirmación es correcta.
#define MY_COMPILETIME_ASSERT(test) \
do { \
extern void you_did_something_bad(void); \
if (!(test)) \
you_did_something_bad(void); \
} while (0)
Si bien este mecanismo funciona (siempre que las optimizaciones estén habilitadas), tiene la desventaja de no informar un error hasta que se vincula, momento en el que no puede encontrar la definición de la función you_hizo_algo_malo(). Es por eso que los desarrolladores del kernel comenzaron a usar trucos como los anchos de campo de bits de tamaño negativo y las matrices de tamaño negativo (el último de los cuales dejó de romper compilaciones en GCC 4.4).
En simpatía por la necesidad de aserciones en tiempo de compilación, GCC 4.3 introdujo el error atributo de función que le permite ampliar este concepto anterior, pero generar un error de tiempo de compilación con un mensaje de su elección:¡no más mensajes de error crípticos de "matriz de tamaño negativo"!
#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 hecho, a partir de Linux 3.9, ahora tenemos una macro llamada compiletime_assert que usa esta característica y la mayoría de las macros en bug.h se han actualizado en consecuencia. Aún así, esta macro no se puede usar como inicializador. Sin embargo, el uso de expresiones de declaración (otra extensión GCC C), ¡tú puedes!
#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; \
})
Esta macro evaluará su parámetro exactamente una vez (en caso de que tenga efectos secundarios) y creará un error en tiempo de compilación que dice "¡Te dije que no me dieras un cinco!" si la expresión se evalúa como cinco o no es una constante de tiempo de compilación.
Entonces, ¿por qué no usamos esto en lugar de campos de bits de tamaño negativo? Por desgracia, actualmente existen muchas restricciones en el uso de expresiones de declaración, incluido su uso como inicializadores constantes (para constantes de enumeración, ancho de campo de bits, etc.) incluso si la expresión de declaración es completamente constante en sí misma (es decir, puede evaluarse completamente). en tiempo de compilación y, de lo contrario, pasa el __builtin_constant_p() prueba). Además, no se pueden usar fuera del cuerpo de una función.
Con suerte, GCC corregirá estas deficiencias pronto y permitirá que las expresiones de declaraciones constantes se usen como inicializadores constantes. El desafío aquí es la especificación del lenguaje que define qué es una expresión legal constante. C ++ 11 agregó la palabra clave constexpr solo para este tipo o cosa, pero no existe una contraparte en C11. Si bien C11 obtuvo aserciones estáticas, que resolverán parte de este problema, no resolverá todas estas deficiencias. Así que espero que gcc pueda hacer que una funcionalidad constexpr esté disponible como una extensión a través de -std=gnuc99 &-std=gnuc11 o algo así y permita su uso en expresiones de declaración et. al.
El : es un campo de bits. En cuanto a !! , esa es una doble negación lógica y, por lo tanto, devuelve 0 para falso o 1 de verdad. Y el - es un signo menos, es decir, una negación aritmética.
Todo es solo un truco para hacer que el compilador vomite en entradas no válidas.
Considere BUILD_BUG_ON_ZERO . Cuando -!!(e) evalúa a un valor negativo, que produce un error de compilación. De lo contrario -!!(e) se evalúa como 0, y un campo de bits de ancho 0 tiene un tamaño de 0. Y, por lo tanto, la macro se evalúa como size_t con valor 0.
En mi opinión, el nombre es débil porque, de hecho, la compilación falla cuando la entrada es no. cero.
BUILD_BUG_ON_NULL es muy similar, pero produce un puntero en lugar de un int .