| Age | Commit message (Collapse) | Author |
|---|
|
Previously setting LIBC_COPT_STRING_UNSAFE_WIDE_READ would cause a build
error because there is a path in the ifdef that doesn't return anything.
|
|
The string_utils.h file previously included both memcpy and bzero. There
were no uses of bzero, and only one use of memcpy which was replaced
with __builtin_memcpy.
Also fix strsep which was broken by this change, fix a useless assert of
"sizeof(char) == sizeof(cpp::byte)", and update the bazel.
|
|
Relates to
https://github.com/llvm/llvm-project/issues/119281#issuecomment-2699470459
|
|
This reverts commit 1e6e845d49a336e9da7ca6c576ec45c0b419b5f6 because it
changed the 1st parameter of adjust() to be unsigned, but libc itself
calls adjust() with a negative argument in align_backward() in
op_generic.h.
|
|
Relates to: #119281
|
|
Update string_utils' string_length to work with char* or wchar_t*, so that it
may be reusable when implementing wmemchr, wcspbrk, wcsrchr, wcsstr.
Link: #121183
Link: #124027
Co-authored-by: Nick Desaulniers <ndesaulniers@google.com>
---------
Co-authored-by: Tristan Ross <tristan.ross@midstall.com>
|
|
|
|
`strrchr("foo", '\0')` is defined to point to the end of `foo`, rather
than returning NULL. This wasn't caught by tests, since llvm-libc's
`ASSERT_STREQ(nullptr, "");` is not an assertion error.
While I'm here, refactor the test slightly to check for NULL more
specifically. I considered adding fancier `ASSERT`s (and changing the
semantics of `ASSERT_STREQ`), but opted for a more local fix by fair
dice roll.
|
|
When running Bionic's testsuite over llvm-libc, tests broke because
e.g.,
```
const char *str = "abc";
char buf[7]{"111111"};
strlcpy(buf, str, 7);
ASSERT_EQ(buf, {'1', '1', '1', '\0', '\0', '\0', '\0'});
```
On my machine (Debian w/ glibc and clang-16), a `printf` loop over `buf`
gets unrolled into a series of const `printf` at compile-time:
```
printf("%d\n", '1');
printf("%d\n", '1');
printf("%d\n", '1');
printf("%d\n", 0);
printf("%d\n", '1');
printf("%d\n", '1');
printf("%d\n", 0);
```
Seems best to match existing precedent here.
|
|
This is a part of #97655.
|
|
declaration" (#98593)
Reverts llvm/llvm-project#98075
bots are broken
|
|
This is a part of #97655.
|
|
This is step 4 of
https://discourse.llvm.org/t/rfc-customizable-namespace-to-allow-testing-the-libc-when-the-system-libc-is-also-llvms-libc/73079
|
|
prevent file copy/paste issues. (#66477)
|
|
(#66226)
The name has been changed to adhere to the config option naming format.
The necessary build changes to use the new option have also been made.
|
|
This was generated using clang-tidy and clang-apply-replacements,
on src/string/*.cpp for just the llvmlibc-inline-function-decl
check, after applying https://reviews.llvm.org/D157164, and then
some manual fixup.
Reviewed By: abrachet
Differential Revision: https://reviews.llvm.org/D157169
|
|
This patch mostly renames files so it better reflects the function they declare.
Reviewed By: michaelrj
Differential Revision: https://reviews.llvm.org/D155607
|
|
Fix a bunch more instances of incorrect use of the `static`
keyword and missing use of LIBC_INLINE and LIBC_INLINE_VAR
macros. Note that even forward declarations and generic template
declarations must follow the prescribed patterns for libc code so
that they match every definition, all template specializations.
Reviewed By: Caslyn
Differential Revision: https://reviews.llvm.org/D154260
|
|
Differential Revision: https://reviews.llvm.org/D147463
|
|
Differential Revision: https://reviews.llvm.org/D147503
|
|
Differential Revision: https://reviews.llvm.org/D144995
|
|
Rename preprocessor definitions that control tuning of llvm libc.
Differential Revision: https://reviews.llvm.org/D143913
|
|
|
|
|
|
Reviewed By: lntue
Differential Revision: https://reviews.llvm.org/D142398
|
|
The only safe way to implement strlen involves reading the string one
char at a time. It is faster to read in larger blocks, but this leads to
reading beyond the string boundary, which is undefined behavior. This
patch adds an implementation and flag to use this fast but unsafe
version of strlen.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D129808
|
|
The `strdup` family of functions rely on `malloc` to be implemented.
Its presence in the `string_utils.h` header meant that compiling many of
the string functions relied on `malloc` being implementated as well.
This patch simply moves the implementation into a new file to avoid
including `stdlib.h` from the other string functions. This was a barrier
for compiling string functions for the GPU where there is no malloc
currently.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D138607
|
|
Reviewed By: michaelrj
Differential Revision: https://reviews.llvm.org/D135905
|
|
This allows for easier discovery.
|
|
|
|
|
|
Differential Revision: https://reviews.llvm.org/D125978
|
|
The idea is to move all pieces related to the actual libc sources to the
"src" directory. This allows downstream users to ship and build just the
"src" directory.
Reviewed By: michaelrj
Differential Revision: https://reviews.llvm.org/D112653
|
|
While working and testing my refactoring of multiple string functions in libc, I came across a bug that needs to be addressed in a patch on its own: src is checked for nullptr and assigned to *saveptr if it is nullptr. However, saveptr is initially nullptr when it comes to reentry. This could cause a problem if both saveptr and src are null; we need to do the check first and return nullptr if both are nullptr.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D106885
|
|
This revision removes dependencies that exist between different string functions. This allows for the libc user to use a specific function X of this library without also depending on Y and Z.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D87421
|
|
scheme to TableGen files.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D85945
|
|
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D85779
|
|
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D85615
|
|
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D85386
|
