Fix binding of null pointer dereference to reference type

core/fxcrt/include/fx_basic.h

Index: core/fxcrt/include/fx_basic.h
diff --git a/core/fxcrt/include/fx_basic.h b/core/fxcrt/include/fx_basic.h
index 7121ffcd0bd81cd8cb4d4932fa18dbd1c7ed4e87..90d0bda8702af16ffed95728659155562ebf1168 100644
--- a/core/fxcrt/include/fx_basic.h
+++ b/core/fxcrt/include/fx_basic.h
@@ -8,6 +8,7 @@
 #define CORE_FXCRT_INCLUDE_FX_BASIC_H_
 
 #include <algorithm>
+#include <cstdlib>
 #include <memory>
 
 #include "core/fxcrt/include/fx_memory.h"
@@ -277,7 +278,7 @@ class CFX_ArrayTemplate : public CFX_BasicArray {
 
   const TYPE GetAt(int nIndex) const {
     if (nIndex < 0 || nIndex >= m_nSize) {
-      return (const TYPE&)(*(volatile const TYPE*)NULL);
+      abort();
     }
     return ((const TYPE*)m_pData)[nIndex];
   }
@@ -292,7 +293,7 @@ class CFX_ArrayTemplate : public CFX_BasicArray {
 
   TYPE& ElementAt(int nIndex) {
     if (nIndex < 0 || nIndex >= m_nSize) {
-      return *(TYPE*)NULL;
+      abort();

[dsinclair, 2016/05/16 17:41:02]

I don't think this is safe to do. We can't assume the current library isn't
depending on this behaviour and we're now going to start aborting where we'd
have continued previously.

[hans, 2016/05/16 17:48:26]

Getting a reference bound to null as the return value sounds like a horrible
thing to depend on :-)

I think the intention of the code is clearly to abort here.

Grepping the source for callers at ElementAt, I don't see anything that would
crash immediately on a reference-to-null.

[Tom Sepez, 2016/05/16 17:49:18]

But .. they wanted to crash here, so this should be fine. Unfortunately, we
wouldn't do so in many platforms since the optimizer can assume that null derefs
never occur, and hence remove this deliberate null deref.

[Nico, 2016/05/16 17:49:34]

References pointing to null have undefined behavior, and compilers do exploit
this. Since this is an inline function in a header file, the compiler could do
arbitrary things at calling points if it knows at compile time that nIndex is 0
or >= m_nSize. So that needs to be fixed anyhow. Now this'll provide a clean
crash report when that happens and we'll learn about it. It might cause
short-term pain, but it's the right change going forward.

(Maybe this should use something like blink's IMMEDIATE_CRASH instead of abort
though, not sure.)

     }
     return ((TYPE*)m_pData)[nIndex];
   }