Clarification on undefined behaviour and/or how to get warned for these

Clang Frontend
1

Hi,

I’m fairly new to the world of C compiler edge cases and their undefined behaviour or what the C standards say about this particular one, but as it’s behaviour changed ‘recently’ I’d like to ask for some clarification nonetheless.

Since moving the build process of our iOS app to Xcode 7, an animation that was expected to run for a long time suddenly ran for a very short period. The issue turned out to be a change in how HUGE_VAL as an argument was converted to a long, which is the parameter type the function expected. The full case in question can be found here https://github.com/artsy/eigen/issues/838#issuecomment-145600551, but I have reduced it to the following example for ease of understanding.

2

UBSan catches this

$ clang+±tot undef.cpp -fsanitize=undefined
$ ./a.out
undef.cpp:14:8: runtime error: value inf is outside the range of representable values of type ‘long’

3

Ok, interesting, I had to use -fsanitize=undefined-trap -fsanitize-undefined-trap-on-error, so I guess this is just an issue with the clang being included not having the current UBSan yet.

Thanks!

4

Ok, interesting, I had to use
`-fsanitize=undefined-trap -fsanitize-undefined-trap-on-error`, so I guess
this is just an issue with the clang being included not having the current
UBSan yet.

Perhaps you don't have compiler-rt? I think the trap behavior is an
alternative when there's no runtime support (that provides the pretty
diagnostics, etc).