[libc-commits] [libc] [libc] Fix undefined behavior for nan functions. (PR #106468)

[Michael Jones via libc-commits]

================
@@ -1208,6 +1210,15 @@ template <class T> LIBC_INLINE StrToNumResult<T> strtonan(const char *arg) {
   using FPBits = typename fputil::FPBits<T>;
   using StorageType = typename FPBits::StorageType;
 
+#ifndef LIBC_HAS_SANITIZER
+  if (LIBC_UNLIKELY(arg == nullptr)) {
+    // Use volatile to prevent undefined behavior of dereferencing nullptr.
----------------
michaelrj-google wrote:

>From what I understand, the only time this will matter is when all of the following conditions are met:
a) User code is built alongside libc code as source
b) The code is built without sanitizers
c) The code is built with optimizations
d) The code passes a nullptr to the `nan` function in a constant way.

In that case, the user code is incorrect (it should not pass nullptr to `nan`) and the compiler may do unexpected things. I agree that this check would help find the bug in this specific case, but it will have a penalty for every other case, since this check can't be optimized out due to the `volatile`. Additionally, if the user code does have this undefined behavior, then they can find it by changing any of the conditions (e.g. building with sanitizers) without us needing this check all the time.

My main point is: If the user wants hardening to find this sort of undefined behavior, they have access to it. If they didn't choose to use hardening then they may not want it.

https://github.com/llvm/llvm-project/pull/106468