Although this article points out that UE4 doesn't use synamic_cast, Unreal implements a full reflection system and uses it instead. Similarly, if you searched for uses of stl, you'd be is appointed because everything is reimplemented as TArray, TPair, TMap, etc.
I'd prefer to see this either with inline assembly, or using __debugbreak() (and variants for other compilers). I'd say it's a deref because many compilers don't generate inline-asm for 64-bit skus. This makes the instruction always emitted, and then 64-bit platforms ignore it. But not always (recent claims say it works: http://stackoverflow.com/questions/3634124/where-did-int-3-g...).
Int3 is a one byte instruction, how do you imagine this code could possibly compile into one byte? This will compile into several moves/stores. Not to mention the code is not x86 specific at all.
It's a forced memory access violation and the 3 is used to distinguish it from a natural one: when you hit this you will see an immediate 3 load nearby and that's a constant that is rarely seen in code normally.
"Not to mention the code is not x86 specific at all."
Technically no, however it's only used in x86. It's only ever called if PLATFORM_EXCEPTIONS_DISABLED is 0. If you look up where PLATFORM_EXCEPTIONS_DISABLED is defined in Platform.h, you'll see it's only defined when not using PLATFORM_DESKTOP. PLATFORM_DESKTOP is disabled for Android, HTML5, iOS, WinRT, and WinRTArm. PLATFORM_DESKTOP is enabled for Linux, Mac, and Windows. So that instruction is only intended to be used in x86 desktop environments.
Considering this, I don't think RaiseException is well defined. If it's only meant to be used for x86, it should be coded that way instead of relying on other code to enforce the behavior.
if PLATFORM_EXCEPTIONS_DISABLED means if it is not 0. if !PLATFORM_EXCEPTIONS_DISABLED means if it is 0, if it is not disabled. I said nothing incorrect, I'm well aware of what it means.
You said the code is being called only if PLATFORM_EXCEPTIONS_DISABLED is 0. This is incorrect. Just compile that function and set the breakpoints if you cannot figure out the #if/#else logic.
It's getting hit because you're running on Windows/Mac and Windows/Mac specific methods are calling it. In platform generic code like OutputDevices.cpp you see this:
I see. You are saying that because a library/framework is not calling one of its own functions in a certain configuration nobody ever going to call this function in that configuration, right? I am not sure I can join you in this belief, after all there are not that many fully recursive libraries so some functions will never be called in almost every library.
"You are saying that because a library/framework is not calling one of its own functions in a certain configuration nobody ever going to call this function in that configuration, right?"
I'm not saying that at all, I said early on that this is a problem. Refer to this in my first comment replying to you: "I don't think RaiseException is well defined. If it's only meant to be used for x86, it should be coded that way instead of relying on other code to enforce the behavior."
Internally it seems they only intended it to be used in specific cases, but there's nothing preventing anyone else from calling it when they shouldn't as you noted. This is bad design.
