Summary:
This is supposed to define the maximum bytes required to store a char in
any locale. There's some question about what this should be set to. I
believe because the proposed solution for `locale.h` is to only support
the default locale, we should do what `musl` does and set it to `4`
which covers up to UTF-32.
Fixes https://github.com/llvm/llvm-project/issues/79358
Summary:
Currently we use `(~0U)` for this definition, however the ~ operator
returns a different sign, meaning that preprocessor checks against this
value will fail. See https://godbolt.org/z/TrjaY1d8q where the
preprocessor thinks that it's not `0xffffffff` while the static
assertion thinks it is. This is because the latter does implicit
conversion but the preprocessor does not. This is now consistent with
other headers.
Towards the goal of getting `ninja libc-lint` back to green, fix the numerous
instances of:
warning: header guard does not follow preferred style [llvm-header-guard]
This is because many of our header guards start with `__LLVM` rather than
`LLVM`.
To filter just these warnings:
$ ninja -k2000 libc-lint 2>&1 | grep llvm-header-guard
To automatically apply fixits:
$ find libc/src libc/include libc/test -name \*.h | \
xargs -n1 -I {} clang-tidy {} -p build/compile_commands.json \
-checks='-*,llvm-header-guard' --fix --quiet
Some manual cleanup is still necessary as headers that were missing header
guards outright will have them inserted before the license block (we prefer
them after).
The standard requires `limits.h` constants to be used in preprocessors.
So we use `__SIZEOF_LONG__` instead of `sizeof(long)` to define
`LONG_WIDTH`. The macro `__SIZEOF_LONG__` seems to be available on both
clang and gcc since at least version 9.
limits.h currently interferes with Clang's limits.h. include_next
emits a warning because it is a GNU extension. Will re add this once
we figure out a good solution.
This reverts commits 13bbca8d694b4ef2ad03ec1805f07da8640c1a31,
002cba03298a7e8f0c1cadcb7996379e9ea5feff, and
0fb3066873fdfbe28dbb6409c58a8bff7cf208c6.
The LLVM-libc build itself will override include paths and prefer it's
own limits.h over the compiler's limits.h. Because we rely on the
compiler limits.h for numerical limits in LLVM-libc it needs to be
include_next:ed if not already included. The other method to work
around this is to define all numeric macros in place.
Signed-off-by: Alfred Persson Forsberg <cat@catcream.org>
Reviewed By: thesamesam
Differential Revision: https://reviews.llvm.org/D158040
This header contains implementation specific constants.
The compiler already provides its own limits.h with numerical limits
conforming to freestanding ISO C. But it is missing extensions like
POSIX, and does for example not include <linux/limits.h> which is
expected on a Linux system, therefore, an LLVM libc implementation of
limits.h is needed for hosted (__STDC_HOSTED__) environments.
Reviewed By: michaelrj
Differential Revision: https://reviews.llvm.org/D156961
