It was a bit odd that you could create a Userspace<int> and that
Userspace<int>::ptr() returned an int instead of an int*.
Let's use C++20 concepts to only allow creating Userspace objects with
pointer types. :^)
Since we already have the type information in the Userspace template,
it was a bit silly to cast manually everywhere. Just add a sufficiently
scary-sounding getter for a typed pointer.
Thanks @alimpfard for pointing out that I was being silly with tossing
out the type.
In the future we may want to make this API non-public as well.
This will be used in the kernel to wrap pointers into userspace memory
without convenient direct access. The idea is to use the compiler to
enforce that we don't dereference userspace pointers.
I accidently wrote `Span<RemoveConst<T>>` when I meant
`Span<RemoveConst<T>::Type>`.
Changing that wouldn't be enough though, this constructor can only be
defined if T is not const, otherwise it would redefine the copy
constructor. This can be avoided by overloading the cast operator.
There's no great advantage to using MMX instructions here on modern
processors, since REP MOVSB/STOSB are optimized in microcode anyway
and tend to run much faster than MMX/SSE/AVX variants.
This also makes it much easier to implement high-level emulation of
memcpy/memset in UserspaceEmulator once we get there. :^)
Fixes#2776.
This fixes, among other things, JSON serialization.
The underlying bug was that 'print_double' defined fraction_length
as a function argument with a default value, whereas
printf_internal *always* provided a value, even if nothing was read.
The 'use 6 by default' logic has been moved to printf_internal instead.
I totally forgot about the C++ basics here. There are three distinct
types: "char", "signed char" and "unsigned char". Whether "char" is
signed or unsigned is implementation specific.
This allows performing an action based on whether something
was actually added or removed without having to look it up
prior to calling set() or remove().
The fact that JsonValues can contain 64-bit values isn't a JavaScript
compatible behavior in the first place, but as long as we're supporting
this, we should make sure it works correctly.
Prior to this, we wrote to the log every time the << operator
was used, which meant that only these parts of the log statement
were serialized. If the thread was preempted, or especially with
multiple CPUs the debug output was hard to decipher. Instead, we
buffer up the log statements. To avoid allocations we'll attempt
to use stack space, which covers most log statements.
This was showing up in Browser profiles, which is silly, so write a new
version that doesn't create a temporary String object.
There are a whole bunch of these and long-term it would be nice to find
a way to share all the very similar logic instead of duplicating it.
