GCC undefined behaviors are getting wild

Re:GCC undefined behaviors are getting wild by throwaway81523 on Monday November 28, 2022 @05:29AM (#33771875)

-fwrapv introduces runtime bugs on purpose! The last thing you want is an unexpected situation where n is an integer and n+1 is somehow less than n. And of course that bug has good chances of leading to UB elsewhere, such as a bad subscript. If you want to protect from UB on int overflow, -ftrapv (not -fwrapv) is the only sane approach. Then at least you'll throw an exception, similar to range checking subscripts.

It is sad that we don't get hardware assistance for that trap on any widespread cpu, at least that I know of.

[ Parent | on HN ]

Re:GCC undefined behaviors are getting wild by Asooka on Monday November 28, 2022 @05:33AM (#33771905)

It's not to protect from UB, it's to protect from the optimiser deleting your bounds checks.

[ Parent | on HN ]

Re:GCC undefined behaviors are getting wild by lilllly on Monday November 28, 2022 @06:33AM (#33772339)

I can easily test if n+1 is < n with fwrapv.

Without you have to do convoluted things like rearranging the expression to unnatural forms (move the addition to the right but invert to subtraction, etc), special case INT_MAX/INT_MIN, and so on - which you then have to hope the compiler is smart enough to optimize, which it often isn't (oh how ironic).

[ Parent | on HN ]

Re:GCC undefined behaviors are getting wild by caf on Monday November 28, 2022 @07:57PM (#33782242)

On x86 you can put an INTO instruction after each arithmetic operation to trap if the overflow flag is set.

[ Parent | on HN ]