But there's nothing in your code that suggests that there's a problem if the error and success fields are both true. Typically you'd have at least an assert (a

But there's nothing in your code that suggests that there's a problem if the error and success fields are both true. Typically you'd have at least an assert (and hopefully some unit tests) to ensure that invariant (.success ^ .error == true). But the code has just been getting by on the good graces of the previous stack contents. One random day, the app behaviour changed and left a non-zero byte that the response struct picked up and left the app in the alternate reality where .success == .error Others have mentioned sanitizers that may expose the problem. Microsoft's Visual C++ compiler has the RTCs/RTC1 compiler switch which fills the stack frame with a non-zero value (0xCC). Using that compiler switch would have exposed the problem. You could also create a custom __chkstk stack probe function and have GCC/Clang use this to fill the stack as well as probing the stack. I did this years ago when there was no RTCs/RTC1 compiler option available in VC++.