4 ms·
If I understand it right, in principle the compiler doesn't even need to do that. It can just leave the result totally uninitialised. That's because both code
by quietbritishjim 10mo ago
If I understand it right, in principle the compiler doesn't even need to do that.
It can just leave the result totally uninitialised. That's because both code paths have undefined behaviour: whichever of result.x or result.y is not set is still copied at "return result" which is undefined behaviour, so the overall function has undefined behaviour either way.
It could even just replace the function body with abort(), or omit the implementation entirely (even the ret instruction, allowing execution to just fall through to whatever memory happens to follow). Whether any computer does that in practice is another matter.
- masklinn 10mo ago> It can just leave the result totally uninitialised. That's because both code paths have undefined behaviour: whichever of result.x or result.y is not set is still copied at "return result" which is undefined behaviour, so the overall function has undefined behaviour either way. That is incorrect, per the resolution of DR222 (partially initialized structures) at WG14: > This DR asks the question of whether or not struct assignment is well defined when the source of the assignment is a struct, some of whose members have not been given a value. There was consensus that this should be well defined because of common usage, including the standard-specified structure struct tm. As long as the caller doesn't read an uninitialised member, it's completely fine.
- tialaramex 10mo agoOoh, thanks for mentioning DR222 that's very interesting.