Store the ratio between device and CSS pixels on the PaintContext, so
that it can convert between the two.
Co-authored-by: MacDue <macdue@dueutil.tech>
This patch adds the `find_executable()` function that will hopefully
find executables in a distro-agnostic way and that is (hopefully as
well) easily upgradable.
The function uses some bash functionalities. So, we now require bash
for each script that includes `.shell_include.sh`.
We return early from the DateTimeFormat constructor to avoid crashing on
assertions when the CLDR is disabled. However, after commit 019211b, the
spec now mandates we assert the time zone identifier is valid. The early
return resulted in this identifier being an empty string.
This now allows you to select a background color for your new image,
and optionally allows saving that default. You can pick between
Transparent, White, Black, or a custom color (similar to other
editors).
This now only requires `size + alignment` bytes while searching for a
free memory location. For the actual allocation, the memory area is
properly trimmed to the required alignment.
This keeps us from tripping strict aliasing, which previously made TCP
connections inoperable when building without `-fsanitize=undefined` or
`-fno-strict-aliasing`.
This patch validates that the size of the auxiliary vector does not
exceed `Process::max_auxiliary_size`. The auxiliary vector is a range
of memory in userspace stack where the kernel can pass information to
the process that will be created via `Process:do_exec`.
The reason the kernel needs to validate its size is that the about to
be created process needs to have remaining space on the stack.
Previously only `argv` and `envp` were taken into account for the
size validation, with this patch, the size of `auxv` is also
checked. All three elements contain values that a user (or an
attacker) can specify.
This patch adds the constant `Process::max_auxiliary_size` which is
defined to be one eight of the user-space stack size. This is the
approach taken by `Process:max_arguments_size` and
`Process::max_environment_size` which are used to check the sizes
of `argv` and `envp`.
We previously depended on sudo's specific -E flag to keep all the
environment variables when performing a privilege escalation. We now
incorporate the -E flag into the $SUDO variable, allowing for other
privilege escalation binaries (such as doas) to be used (as long as
they preserve the current environment variables).
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
In the long run, this is obviously a bad way to handle version changes
to the SQL database files. We will want to migrate old databases to new
formats. Until we figure out a good way to do that, wipe old databases
so that we don't crash trying to read incompatible data.
GCPtr can be null so it's not safe to assign it to a NonnullGCPtr unless
you know it to be non-null.
This exposed a number of wrong uses in LibWeb which had to be fixed as
part of this change.
This constructor was easily confused with a copy constructor, and it was
possible to accidentally copy-construct Objects in at least one way that
we dicovered (via generic ThrowCompletionOr construction).
This patch adds a mandatory ConstructWithPrototypeTag parameter to the
constructor to disambiguate it.
It was possible for the generic ThrowCompletionOr constructor to
"copy-construct" a JS Object when instantiating a ThrowCompletionOr
via e.g `return *object;`.
This happened because it chose the Object(Object& prototype) constructor
which will be removed in a subsequent commit. It was not easy to debug.
As a first step towards avoiding this in the future, the generic
ThrowCompletionOr constructor now takes the value as a const reference.
