0
298
Vistas¿Es un comportamiento indefinido usar funciones con efectos secundarios en un orden no especificado?
Sé que cosas como x = x++ + ++x invocan un comportamiento indefinido porque una variable se modifica varias veces dentro del mismo punto de secuencia. Eso se explica a fondo en esta publicación. ¿Por qué estas construcciones utilizan un comportamiento indefinido previo y posterior al incremento?
Pero considere algo como printf("foo") + printf("bar") . La función printf devuelve un int , por lo que la expresión es válida en ese sentido. Pero el orden de evaluación del operador + no se especifica en el estándar, por lo que no está claro si imprimirá foobar o barfoo .
Pero mi pregunta aquí es si esto también es un comportamiento indefinido.
3 Respuestas
Responde la pregunta0
No, no es.
Es un comportamiento no especificado
0
Probablemente esté preguntando porque un programa que intenta leer un valor no especificado (por ejemplo, int no inicializado) tiene un comportamiento indefinido.
Ese no es el caso con el orden no especificado o las operaciones secuenciadas indeterminadamente. No sabes lo que obtendrás, pero el programa tiene un comportamiento bien definido.
La escritura en stdout no causa ningún problema porque el valor tampoco es "no especificado" en ese sentido. Puede considerarlo más como un valor definido por la implementación, como resultado del orden no especificado.
tl; dr: no todo lo "no especificado" lleva a ser "indefinido".
0
Como se señaló en otra parte, si se utilizan dos llamadas de función en una expresión, un compilador puede elegir de forma no especificada cuál se invocará primero, pero todas las partes de una operación (elegida de forma no especificada) deben preceder a todas las partes de la otra. Por el contrario, si dos operaciones no están secuenciadas, un compilador puede intercalar las partes de la operación.
Sin embargo, un punto que no he visto mencionado es que, si bien muchos compiladores están diseñados para procesar ciertas operaciones en tipos primitivos de tal manera que las distinciones entre "sin secuencia" y "con secuencia indeterminada" no importan, algunos optimizadores pueden producir máquinas código donde tales cosas podrían importar, especialmente en escenarios de subprocesos múltiples, por lo que es bueno preocuparse por tales distinciones.
Considere una función como la siguiente, si es procesada por gcc 9.2.1 con opciones -xc -O3 -mcpu=cortex-m0 [el Cortex-M0 es un popular núcleo de producción actual de 32 bits que se encuentra en los microcontroladores de gama baja]:
#include <stdint.h> uint16_t incIfUnder32768(uint16_t *p) { uint16_t temp = *p; return temp - (temp >> 15) + 1; } Uno podría esperar que si otro subproceso cambiara *p durante la función, realizaría el cálculo en función del valor de *p antes del cambio, o realizaría el cálculo en función del valor posterior. Sin embargo, el optimizador para gcc 9.2.1 generará código de máquina como si se hubiera escrito el código fuente:
#include <stdint.h> uint16_t incIfUnder32768(uint16_t *p) { return *p - (*p >> 15) + 1; } Si el valor de *p cambiara, por ejemplo, de 0xFFFF a 0 , o de 0 a 0xFFFF, la función podría devolver 0xFFFF aunque no habría ningún valor que *p pudiera haber tenido para producir ese resultado.
Aunque los compiladores, cuando se escribió el estándar, casi invariablemente ampliaban la semántica del lenguaje al procesar muchas acciones "de una manera documentada característica del entorno", independientemente de si el estándar les obligaba a hacerlo, algunos escritores de compiladores "inteligentes" buscan aprovechar las oportunidades en las que desviarse de tales comportamientos permitiría "optimizaciones" que podrían o no hacer que el código sea más eficiente.