Take look at the code that follows.
"Hello " "World!";
"The number is ", 37;
int x=23;
char *y="232";
x,x+2,x*3;
atoi(y) - x;
It is a perfectly valid fragment of C(99) source. But! All that expressions return to nowhere! How can one trace or even use all this anonymous values? Where are they stored and what is their purpose?
These values go nowhere. You can not retrieve them. In fact, most are optimized out by the compiler.
That entire fragment can be simplified to atoi("232") because function calls usually can't be optimized out.
Those particular expressions are useless. On the other hand, this is allowed because some expressions have side effects(and perhaps return values), and sometimes only the side effect is needed.
Expressions that don't have side effects aren't particularly useful. Usually you find a function call at those places, and the function body actually causes some state change in the program.
Languages have lots of silly ways to do nothing. Consider the C statement:
;
It doesn't do anything.
Are you asking if this:
int main() {
1;
}
is valid C code? If so, yes it is, and always has been.
The comma operator evaluates expressions in order and returns the value of the last one. It's only useful if the previous expressions perform side effects like assignment.
So far as I can tell, the use of comma here is superfluous, and the expressions' values are being thrown away - you can't retrieve them. Unless you're writing these lines in the context of a special C interpreter...?
The same happens every time you call printf(3) without checking its return value, which is discarded. The function call though might have side-effects (printf(3) certainly does), so the instructions to execute it are still generated. Most modern compilers will remove most of the statements you listed given appropriate optimization flags.
If you really want to see what happens, compile your source to assembly (-S option for GCC) with (say -O2) and without optimization and trace the instructions.
From a functional point of view, all those expressions' results are lost. If good optimizations are at work, they are not computed at all. But let us suppose they are. In this case "where" the results are available depends on how the compiler translated the code, a fact that can be considered unpredictable.
On x86 machines, you can think that integer results and pointer results are stored into eax (that then will be trashed), but it is just a supposition; if it is true for a specific compiler and code, it could be not for another compiler or if you change a bit the code. It could also happen that the values are pushed on the stack, which then it's incremented again, so that, until it is not reused, you can find the value on the stack. Same arguments as for eax can be done.
The part tied through the comma are someway different. Things like a, b are read as "execute a, discard any result and then execute b", so that the result of a is lost "by definition" (of course, looking at the asm code, you could also in this case find that it is still available somewhere, but likely it is indeed not after b is evaluated)