What's the reason that C didn't define the order of this? The horrible undefined behavior of signed integer overflow at least can be explained by the fact that multiple CPU architectures handling those differently existed (though the fact that C even 'attracts' its ill-defined signed integers when you're using unsigned ones by returning a signed int when left shifting an uint16_t by an uint16_t for example is not as…
It's valuable for compilers to be able to choose the instruction scheduling order. Standards authors try not to unnecessarily bind implementors. If post increment happened after the full statement is finished, then the original value has to be maintained until the next sequence point. Maybe the compiler will be smart enough to elide that, maybe not, but it's a lot more difficult to fix those kinds of edge cases than…
Int a = 5; a = a++ + ++a; a =? (2011)
21–30 of 246 posts
Re: Int a = 5; a = a++ + ++a; a =? (2011)
#22The code in the post seems very similar to the one in my own post from 2010: https://susam.net/sequence-points.html int a = 5; a += a++ + a++; I do remember that this particular code snippet (with a = 5, even) used to be popular as an interview question. I found such questions quite annoying because most interviewers who posed them seemed to believe that whatever output they saw with their compiler version was the co…
If you can convince someone in a position of authority that they’re wrong about something technical without upsetting them then you’re probably a good culture fit and someone who can raise the average effectiveness of your team.
Re: Int a = 5; a = a++ + ++a; a =? (2011)
#23The code in the post seems very similar to the one in my own post from 2010: https://susam.net/sequence-points.html int a = 5; a += a++ + a++; I do remember that this particular code snippet (with a = 5, even) used to be popular as an interview question. I found such questions quite annoying because most interviewers who posed them seemed to believe that whatever output they saw with their compiler version was the co…
These sorts of things are neat trivia to learn about things like sequence points but 99.9% of the time if it matters in your codebase you're writing something unmaintainable.
Re: Int a = 5; a = a++ + ++a; a =? (2011)
#24The code in the post seems very similar to the one in my own post from 2010: https://susam.net/sequence-points.html int a = 5; a += a++ + a++; I do remember that this particular code snippet (with a = 5, even) used to be popular as an interview question. I found such questions quite annoying because most interviewers who posed them seemed to believe that whatever output they saw with their compiler version was the co…
In some sense, and without the interviewer knowing, that is actually a great scenario for an interview. If you can convince someone in a position of authority that they’re wrong about something technical without upsetting them then you’re probably a good culture fit and someone who can raise the average effectiveness of your team.
Re: Int a = 5; a = a++ + ++a; a =? (2011)
#25> The interesting thing here is the Undefined Behavior (UB), well... actually two UBs, thanks to which there are three possible correct answers: 11, 12 and 13. No, if you invoke undefined behavior any result at all is possible.
The problem is that it’s not specified which should be picked, but all pick something.
Re: Int a = 5; a = a++ + ++a; a =? (2011)
#26What's the reason that C didn't define the order of this? The horrible undefined behavior of signed integer overflow at least can be explained by the fact that multiple CPU architectures handling those differently existed (though the fact that C even 'attracts' its ill-defined signed integers when you're using unsigned ones by returning a signed int when left shifting an uint16_t by an uint16_t for example is not as…
Re: Int a = 5; a = a++ + ++a; a =? (2011)
#27The code in the post seems very similar to the one in my own post from 2010: https://susam.net/sequence-points.html int a = 5; a += a++ + a++; I do remember that this particular code snippet (with a = 5, even) used to be popular as an interview question. I found such questions quite annoying because most interviewers who posed them seemed to believe that whatever output they saw with their compiler version was the co…
In some sense, and without the interviewer knowing, that is actually a great scenario for an interview. If you can convince someone in a position of authority that they’re wrong about something technical without upsetting them then you’re probably a good culture fit and someone who can raise the average effectiveness of your team.
Re: Int a = 5; a = a++ + ++a; a =? (2011)
#28Tried it on https://www.onlinegdb.com/online_c_compiler Returns 12. If I were designing C, it would return 13. But then again, I'm an assembly programmer.
#include
int main() {
int a = 5;
a = a++ + ++a;
printf("%d\n", a);
return 0;
}
x64 msvc v19.50 VS18.2 output: example.c
ASM generation compiler returned: 0
example.c
Execution build compiler returned: 0
Program returned: 0
13
x86-64 gcc 16.1 output: ASM generation compiler returned: 0
Execution build compiler returned: 0
Program returned: 0
12
armv8-a clang 22.1.0 output: :5:10: warning: multiple unsequenced modifications to 'a' [-Wunsequenced]
5 | a = a++ + ++a;
| ^ ~~
1 warning generated.
ASM generation compiler returned: 0
:5:10: warning: multiple unsequenced modifications to 'a' [-Wunsequenced]
5 | a = a++ + ++a;
| ^ ~~
1 warning generated.
Execution build compiler returned: 0
Program returned: 0
12Re: Int a = 5; a = a++ + ++a; a =? (2011)
#29What's the reason that C didn't define the order of this? The horrible undefined behavior of signed integer overflow at least can be explained by the fact that multiple CPU architectures handling those differently existed (though the fact that C even 'attracts' its ill-defined signed integers when you're using unsigned ones by returning a signed int when left shifting an uint16_t by an uint16_t for example is not as…
Re: Int a = 5; a = a++ + ++a; a =? (2011)
#30What's the reason that C didn't define the order of this? The horrible undefined behavior of signed integer overflow at least can be explained by the fact that multiple CPU architectures handling those differently existed (though the fact that C even 'attracts' its ill-defined signed integers when you're using unsigned ones by returning a signed int when left shifting an uint16_t by an uint16_t for example is not as…