"x = ++ x" ¿es realmente indefinido?

Question

Estoy usando Coverity Prevent en un proyecto para encontrar errores.

Se informa de un error para esta expresión (Los nombres de las variables son, por supuesto cambiado):

x= 
    (a>= b) ? 
    ++x: 0; 

El mensaje es: defecto

EVALUATION_ORDER: En "x=(a>= b) ? ++x: 0;", "x" es escrito en "x" (la asignación LHS) y escrito en "(a>= b) ? ++x: 0;", pero el orden en que se producen los efectos secundarios no está definido porque no hay punto de secuencia intermedio. FIN DEL MENSAJE

Si bien puedo entender que "x = x++" no está definido, este es un poco más difícil para mí. ¿Es este un falso positivo o no?

Answer 1

operador condicional ?: tiene un punto de secuencia entre la evaluación de la condición (primer operando) y la evaluación de segundo o tercer operando, pero no tiene ningún punto de secuencia dedicado después de la evaluación de segundo o tercer operando. Lo que significa que dos modificaciones de x en este ejemplo son potencialmente conflictivas (no separadas por un punto de secuencia). Entonces, Coverity Prevent tiene razón.

Su declaración en ese sentido es prácticamente equivalente a

a >= b ? x = ++x : x = 0; 

con el mismo problema que en x = ++x.

Ahora, el título de su pregunta parece sugerir que no sabe si x = ++x no está definido. De hecho, no está definido. No está definido por el mismo motivo x = x++ no está definido. En resumen, si el mismo objeto se modifica más de una vez entre un par de puntos de secuencia adyacentes, el comportamiento no está definido. En este caso, x se modifica por asignación y por ++ y no hay punto de secuencia para "aislar" estas modificaciones entre sí. Entonces, el comportamiento no está definido. No hay absolutamente ninguna diferencia entre ++x y x++ en este sentido.

Answer 2

Independientemente de la precisión del mensaje, al reemplazar el código en cuestión por x= (a>= b) ? x+1: 0; se logra el mismo fin sin confusión. Si la herramienta está confundida, tal vez la siguiente persona que vea este código también lo haga.

Esto supone que x no tiene un operador de incremento sobrecargado con efectos secundarios de los que depende aquí.

Answer 3

La instrucción x = ++x; escribe en la variable x dos veces antes de presionar sequence point y, por lo tanto, el comportamiento no está definido.

Answer 4

Es difícil imaginar un compilador que produzca el código para "x = ++ x;" que de hecho no funcionaría igual que "++ x".Sin embargo, si x no es volátil, sería legal que un compilador procesara la declaración "y = ++ x;" como

 
    y=x+1; 
    x=x+1; 

La declaración "x = ++ x;" se convertiría así en

 
    x=x+1; 
    x=x+1; 

Si tener el destino de una asignación de una expresión aritmética se acostumbre demasiado rápido como operando fuente para otro causaría un retraso tubería, la antigua optimización podría ser razonable. Obviamente desastroso si la variable incrementada y asignada es una y la misma.

Si la variable 'x' es volátil, no puedo pensar en ninguna secuencia de código donde un compilador que no intenta deliberadamente ser malo pueda legítimamente considerar "x = x ++;" como tener cualquier efecto que no sea leer todas las partes de 'x' exactamente una vez y escribir el mismo valor correcto para todas las partes de 'x' exactamente dos veces.

Answer 5

Supongo que, lógicamente, si escribe "x = ++ x" o "x = x ++", de cualquier manera esperaría que el resultado final sea que x es uno más de lo que comenzó. Pero hazlo un poco más complicado. ¿Qué pasa si escribió "x = x + (++ x)"? ¿Es esto lo mismo que "x = x + (x + 1)"? ¿O agregamos uno primero y luego agregamos x a sí mismo, es decir, "x = (x + 1) + (x + 1)"? ¿Qué pasa si escribimos "x = (x -) + (x ++)"?

Incluso si pudiera escribir una especificación de idioma que diera un significado inequívoco a este tipo de construcciones, y podría implementarlo limpiamente, ¿por qué lo haría? Poner un incremento unario en una asignación a la misma variable simplemente no tiene sentido, e incluso si lo forzamos a salir de él, no proporciona ninguna funcionalidad útil. Al igual, estoy seguro de que podríamos escribir un compliler que tome una expresión como "x + 1 = y-1" y descubrir que eso realmente significa "x = y-2", pero ¿para qué molestarse? No hay ganancia.

Incluso si escribiéramos compiladores que hicieran algo predecible con "x = x ++ - ++ x", los programadores tendrían que conocer y comprender las reglas. Sin ningún beneficio obvio, simplemente agregaría complejidad a los programas sin ningún propósito.

Answer 6

Para comprender esto, debe tener una comprensión básica de los puntos de secuencia. Vea este enlace: http://en.wikipedia.org/wiki/Sequence_point

Para el operador = no hay un punto de secuencia, lo que no hay garantía de que el valor de x será modificada antes de que se le asigna de nuevo a x.