In practice, our C++ solutions can be run with the Undefined Behavior Sanitizer (UBSan), which catches issues like bad memory accesses from out-of-bounds array indices and integer overflows. I believe we should be allowed to enable this during actual contest submissions. There could be a checkbox at the bottom saying 'enable diagnostic checks (warning: code may run much slower)' where you can choose to enable it or not. Is this unfair? I don’t think so; UBSan is essentially just a souped-up template, and you can achieve similar effects with assertions like assert(result of addition did not overflow) before every addition or with a template safe int/safe long class that handles it for you, or even using __builtin_add_overflow. Of course, you shouldn’t be told the line number or what the problem was, just a runtime error should suffice (as if you implement it yourself, the only info you get is that a runtime error occurred somewhere). Other languages also have variants of this, like Java's index out of bounds exception (though I don’t believe they natively have overflow detection). This approach is somewhat limited in strength since you’ll likely leave it off on your first submission (or else you’ll definitely TLE), thus incurring a -50 penalty for checking if the issue was an overflow/UB or not. Is this a good idea or just a coping mechanism after failing round 1102 E? While we currently don’t have that, I found it helpful to use an ad blocker to prevent myself from accidentally seeing the 'diagnostics hint' icon, as it’s a big giveaway to the problem. In uBlock Origin Lite, you can create a custom filter to achieve this.
Blogger's Review: Allowing UBSan in contests can effectively reduce errors caused by undefined behavior, enhancing code robustness. However, participants need to weigh performance against safety, using this option judiciously to avoid impacting contest outcomes. Overall, promoting programming safety is a direction worth advocating.