[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