[libc-commits] [libc] [libc][search] implement posix `lfind` function (PR #114692)

Nick Desaulniers via libc-commits libc-commits at lists.llvm.org
Tue Nov 5 09:34:49 PST 2024


================
@@ -0,0 +1,41 @@
+//===-- Implementation of lfind   -------------------------------*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+#include "src/search/lfind.h"
+#include "src/__support/CPP/cstddef.h" // cpp::byte
+#include "src/__support/common.h"
+#include "src/__support/macros/config.h"
+#include "src/__support/memory_size.h"
+
+namespace LIBC_NAMESPACE_DECL {
+LLVM_LIBC_FUNCTION(void *, lfind,
+                   (const void *key, const void *base, size_t *nmemb,
+                    size_t size, int (*compar)(const void *, const void *))) {
+  if (key == nullptr || base == nullptr || nmemb == nullptr ||
+      compar == nullptr)
+    return nullptr;
+
+  size_t byte_len = 0;
+  if (internal::mul_overflow(*nmemb, size, &byte_len))
+    return nullptr;
+
+  const cpp::byte *next = reinterpret_cast<const cpp::byte *>(base);
+  const cpp::byte *end = next + byte_len;
+  while (next < end) {
+    if (compar(key, next) == 0) {
+      // According to IEEE Std 1003.1-2024 we are expected to accept a const
+      // reference to base, but return a non-const reference to the element it
+      // contains.
----------------
nickdesaulniers wrote:

Right, you'd cast away the const via const cast, then reinterpret cast.

```diff
diff --git a/libc/src/search/lfind.cpp b/libc/src/search/lfind.cpp
index 8225e80efd87..da3f1d838928 100644
--- a/libc/src/search/lfind.cpp
+++ b/libc/src/search/lfind.cpp
@@ -7,7 +7,6 @@
 //===----------------------------------------------------------------------===//
 
 #include "src/search/lfind.h"
-#include "src/__support/CPP/cstddef.h" // cpp::byte
 #include "src/__support/common.h"
 #include "src/__support/macros/config.h"
 #include "src/__support/memory_size.h"
@@ -24,17 +23,13 @@ LLVM_LIBC_FUNCTION(void *, lfind,
   if (internal::mul_overflow(*nmemb, size, &byte_len))
     return nullptr;
 
-  const cpp::byte *next = reinterpret_cast<const cpp::byte *>(base);
-  const cpp::byte *end = next + byte_len;
-  while (next < end) {
-    if (compar(key, next) == 0) {
-      // According to IEEE Std 1003.1-2024 we are expected to accept a const
-      // reference to base, but return a non-const reference to the element it
-      // contains.
-      return const_cast<cpp::byte *>(next);
-    }
-    next += size;
-  }
+  auto *next = reinterpret_cast<char *>(const_cast<void*>(base));
+  const char *end = next + byte_len;
+
+  for (; next < end; next += size)
+    if (compar(key, next) == 0)
+      return reinterpret_cast<void*>(next);
+
   return nullptr;
 }
 
```

> The issue here is we are passed a const pointer to the array, but we are expected to return a non-const pointer to the array.

This is a well known issue with the design of many library functions in C (such as `strchr`, `memchr`, `strtof`, `bsearch`, etc) (the recent standards mentions `QChar` and `QVoid` types, 7.26.5.1.2 briefly talks about this); a few functions in the standard library can be used to smuggle or launder away the const. Stated another way, they can be used to attain non-const pointers from parameters that were const.

C also has UB around modifying variables explicitly declared const.  So `const_cast` is dangerous. You'll note in my usage of `const_cast` I'm not mutating the pointed to value (`compar` shouldn't since the callback params are `const` qualified). So it's ok to read through a pointer where `const` has been cast away, but writing is UB.

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


More information about the libc-commits mailing list