0
301
VisualizaçõesIs it undefined behavior to use functions with side effects in an unspecified order?
I know that things like x = x++ + ++x invokes undefined behavior because a variable is modified multiple times within the same sequence point. That's thoroughly explained in this post Why are these constructs using pre and post-increment undefined behavior?
But consider a thing like printf("foo") + printf("bar"). The function printf returns an int, so the expression is valid in that sense. But the order of evaluation for the + operator is not specified in the standard, so it is not clear if this will print foobar or barfoo.
But my question here is if this also is undefined behavior.
3 Respostas
Responde à pergunta0
No it is not.
It is Unspecified Behaviour
0
You're probably asking because a program that tries to read an unspecified value (e.g. uninitialised int) has undefined behaviour.
That is not the case with unspecified order or indeterminately sequenced operations. You don't know what you'll get, but the program has well-defined behaviour.
The writing to stdout doesn't cause a problem because the value is not "unspecified" in that sense either. You can think of it more as an implementation-defined value, as a result of the unspecified ordering.
tl;dr: not everything "unspecified" leads to being "undefined".
0
As noted elsewhere, if two function calls are used in an expression, a compiler may choose in Unspecified fashion which one will be invoked first, but all parts of one operation (chosen in Unspecified fashion) must precede all parts of the other. By contrast, if two operations are unsequenced, a compiler may interleave the parts of the operation.
A point I haven't seen mentioned, however, is that while many compilers are designed to process certain operations on primitive types in such a way that distinctions between "unsequenced" and "indeterminately sequenced" don't matter, some optimizers may produce machine code where such things could matter, especially in multi-threaded scenarios, so it's good to be concerned about such distinctions.
Consider a function like the following, if processed by gcc 9.2.1 with options -xc -O3 -mcpu=cortex-m0 [the Cortex-M0 is a popular current-production 32-bit core found in low-end microcontrollers]:
#include <stdint.h>
uint16_t incIfUnder32768(uint16_t *p)
{
uint16_t temp = *p;
return temp - (temp >> 15) + 1;
}
One might expect that if another thread were to change *p during the function, it would either perform the computation based upon the value of *p before the change, or perform the computation based upon the value after. The optimizer for gcc 9.2.1, however, will generate machine code as though the source code were written:
#include <stdint.h>
uint16_t incIfUnder32768(uint16_t *p)
{
return *p - (*p >> 15) + 1;
}
If the value of *p were to e.g. change from 0xFFFF to 0, or 0 to 0xFFFF, the function might return 0xFFFF even though there would be no value *p could have held that would yield that result.
Although compilers when the Standard was written would almost invariably extend the semantics of the language by processing many actions "in a documented fashion characteristic of the environment" regardless of whether the Standard would require them to do so, some "clever" compiler writers seek to exploit opportunities where deviating from such behaviors would allow "optimizations" that might or might not actually make code more efficient.