JustinStitt wrote: @rjmccall > You linked me to this post promising a detailed discussion of the model, but > I can't quite piece out what overflow model you're actually proposing for the > compliant mode. :)
Sorry, I tried to fit all the information in my post without writing a book. To summarize, the model I propose for "compliant" mode best matches Model 2 from your comment on the RFC. The usual arithmetic conversions take place normally and we bubble up any obt qualifiers through implicit casts. Most of the time we can catch trivial overflow with int-or-greater types like ```c int __ob_trap a = INT_MAX; (a+1); // trap! ``` but for less-than-int cases we can instrument the assignment or storage to trap on truncation: ```c u8 __ob_trap a = 255; u8 = a + 1; // trap! (on assignment truncation) // (a+1) is brought up to an `__ob_trap int` as per usual arithmetic conversions. // that doesn't fit into u8 without data loss. so trap. ``` https://github.com/llvm/llvm-project/pull/148914 _______________________________________________ lldb-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
