Puedo entender eso:
if (i+1 < i) { /* never_executed_code */ } ; UPD: si i es un entero con signo).Sin embargo, todavía no puedo entender por qué el preprocesador C es un sujeto de comportamiento indefinido. Se sabe que las directivas de preprocesamiento se ejecutan en tiempo de compilación.
Considere C11, 6.10.3.3 El operador ##, 3:
Si el resultado no es un token de preprocesamiento válido, el comportamiento no está definido.
¿Por qué no convertirlo en una restricción? Por ejemplo:
El resultado será un token de preprocesamiento válido.
La misma pregunta se aplica a todos los demás "el comportamiento no está definido" en 6.10 Directivas de preprocesamiento.
¿Por qué el preprocesador C es un sujeto de comportamiento indefinido?
Cuando se creó el estándar C, había algunos preprocesadores C existentes y había un preprocesador C ideal imaginario en la mente de los miembros del comité de estandarización.
Así que había estas áreas grises, donde los miembros del comité no estaban completamente seguros de lo que querrían hacer y/o las implementaciones del preprocesador C existentes diferían entre sí en el comportamiento.
Entonces, estos casos no son un comportamiento definido. Porque los miembros del comité C no están completamente seguros de cuál debería ser el comportamiento en realidad. Así que no hay ningún requisito sobre lo que debería ser.
Uno de los orígenes de la UB
Sí, uno de.
UB puede existir para facilitar la implementación del lenguaje. Como por ejemplo, en el caso del preprocesador, los escritores del preprocesador no tienen que preocuparse por lo que sucede cuando un token de preprocesador no válido es el resultado de ## .
O UB puede existir para reconciliar implementaciones existentes con diferentes comportamientos o como un punto para extensiones. Entonces, un preprocesador que falla en el caso de UB, un preprocesador que acepta y funciona en el caso de UB, y un preprocesador que formatea su disco duro en el caso de UB, todos pueden cumplir con el estándar (pero no me gustaría trabajar en eso uno que formatea su disco ).
Supongamos que un archivo que se lee a través de la directiva include termina con la línea parcial:
#define foo bar Según el diseño del preprocesador, es posible que la bar de fichas parcial se concatene con lo que aparezca al comienzo de la línea que sigue a la directiva #include , o que lo que aparezca en esa línea se comporte como si estuviera colocado en la línea. con la directiva #define , pero con un espacio en blanco separándolo de la bar de tokens, y sería difícilmente inconcebible que un script de compilación dependa de tales comportamientos. También es posible que las implementaciones se comporten como si se insertara una nueva línea al final del archivo incluido, o podrían ignorar la última línea parcial de dicho archivo.
Cualquier código que se basara en uno de los comportamientos anteriores claramente no habría sido portátil, pero si el código explotara dicho comportamiento para hacer algo que de otro modo no sería práctico, dicho código difícilmente sería "erróneo", y los autores del estándar lo harían. no haber querido prohibir que una implementación que lo procesaría de manera útil continuara haciéndolo.
Cuando la Norma utiliza la frase "no portátil o erróneo", eso no significa "no portátil, por lo tanto erróneo". Antes de la publicación de C89, las implementaciones de C definían muchas construcciones útiles, pero ninguna de ellas estaba definida por "el estándar C", ya que no había ninguna. Si una implementación definió el comportamiento de alguna construcción, otra no lo hizo, y el Estándar dejó la construcción como "Indefinida", eso simplemente preservaría el status quo donde las implementaciones que optaron por definir un comportamiento útil lo harían, aquellas que eligieron no no lo haría, y los programas que dependieran de tales comportamientos serían "no portátiles", y funcionarían correctamente en implementaciones que admitieran los comportamientos, pero no en aquellas que no lo hicieran.
Sin entrar en detalles, supongo que existen varias implementaciones de preprocesador que tienen errores, pero el Estándar no quiere declararlas no conformes, por razones de compatibilidad.
En lenguaje humano: si escribes un programa que tiene X, el preprocesador hace cosas raras.
En estándar: el comportamiento del programa con X no está definido.
Si el estándar dice algo como "El resultado será un token de preprocesamiento válido", puede que no quede claro qué significa "deberá" en este contexto.