If we do this, the LLVM port's Clang will pick up these paths, so we
won't have to compile libc++ twice. This does increase the size of
_disk_image by 5 MB, but that shouldn't be a problem.
POSIX mandates that the macros contained in `stdint.h` be suitable for
use by the C preprocessor.
If we write `((size_t)-1)`, the C preprocessor will just skip the cast
and treat the value as `-1`. This means that we end up taking the wrong
branch in an `#if` directive like `#if SIZE_MAX > UINT32_MAX`.
This fixes building the LLVM port on i686.
x86_64 is an LP64 platform, so its `uint64_t` type is defined to be
`unsigned long`, not `unsigned long long` like on i686. This means that
the `UL` literal suffix should be used instead of `ULL`.
Furthermore, `uintptr_t` is 64 bits wide on x86_64, so defining
`UINTPTR_MAX` to be `UINT32_MAX` is also not correct.
This will come in handy if we want to use the LLVM port with a GNU host
compiler.
As of version 13, libc++ uses `__attribute__((using_if_exists))` to
import global LibC functions into the `std` namespace, which allows some
symbols to be absent. GCC does not support this attribute, so it fails
to build libc++ due to some obscure `wchar.h` functions. This means that
cross-compiling libc++ is not possible; and on-target builds would be
tedious, so we'll be better off using the toolchain's `libstdc++`.
In order to propagate errors that occur during UI setup, we have to move
all that logic out of widget/window subclass constructors. This is a
first attempt at doing that, for GUI::SettingsWindow.
The fixes are:
1. Don't copy PCI::DeviceIdentifier during construction. This is a heavy
structure to copy so we definitely don't want to do that. Instead, use
a const reference to it like what happens in other parts in the Kernel.
2. Declare the constructor as explicit to avoid construction errors.
It appears that we don't have almost no cases of a callers passing
exec promises when they call `pledge()`. To simplify the code a bit we
add a default parameter that will pass nullptr for us to `pledge()`.
In the spirit of the Core::System name space having "modern" facades
for classically C functions / Kernel interfaces, it seems appropriate
that we should take Span's of data instead of raw pointer + length
arguments.
