If set, this callback gets called right after fork() in the child
process.
It can be used by the caller if it wants to perform some logic in the
child process before it starts executing the debuggee program.
Previously the setup for both the master and slave pseudoterminals was
done in TerminalWrapper::run_command.
This commit separates the relevant logic into
TerminalWrapper::setup_master_pseudoterminal
and TerminalWrapper::setup_slave_pseudoterminal.
At this point, the double conversions should really only be
implementation details of the KeypadValue class. Therefore,
the constructor-from double and conversion-operator-to
double of KeypadValue are made private. Instead, the
required functionality is provided by KeypadValue itself.
The internal implementation is still done using doubles.
However, this opens us up to the possibility of having
loss-free square root, inversion and division in the future.
The Prekernel's memory is only accessed until MemoryManager has been
initialized. Keeping them around afterwards is both unnecessary and bad,
as it prevents the userland from using the 0x100000-0x155000 virtual
address range.
Co-authored-by: Idan Horowitz <idan.horowitz@gmail.com>
As PROT_NONE regions can't be accessed by processes, and their only real
use is for reserving ranges of virtual memory, there's no point in
including them in coredumps.
Since this range is mapped in already in the kernel page directory, we
can initialize it before jumping into the first kernel process which
lets us avoid mapping in the range into init_stage2's address space.
This brings us half-way to removing the shared bottom 2 MiB mapping in
every process, leaving only the Prekernel.
This header defines various constants related to ethernet packets,
with ETH_ALEN being the length of an ethernet address (which is needed
by some ports).
The sa_family field in SIOCGIFHWADDR specifies the underlying network
interface's device type, this is hardcoded to generic "Ethernet" right
now, as we don't have a nice way to query it.
We have close to zero usages of the C string functions in our codebase
(including the "safe" alternatives), so the deprecation warnings are
unlikely to have an actual effect on preventing large-scale use of the
"unsafe" functions.
Meanwhile, the deprecation warnings are causing issues for ports that
are compiled using -Werror by default, and are generally a large source
for logspam when compiling.
I accidentally skipped this part of the spec in the QOI decoder:
> The alpha value remains unchanged from the previous pixel.
This led to incorrect rendering of some images with transparency,
visible in form of a horizontal line of non-transparent pixels (that
shouldn't exist), e.g. for the following chunk sequence:
- QOI_OP_RGBA with alpha = 0
- QOI_OP_RGB
- QOI_OP_RUN
The QOI_OP_RGB should 'inherit' the alpha value of the previous
QOI_OP_RGBA chunk, instead of always setting it to 255.
I'm unsure why the encoder added the QOI_OP_RGB chunk to the specific
image where the bug was noticed in the first place - they effectively
both had fully transparent color values.
This wasn't quite following what the spec says for step 2:
"If index is −1, then remove the last element in the rows collection
from its parent, or do nothing if the rows collection is empty."
It was behaving like:
"If index is −1 and the rows collection is not empty, then remove the
last element in the rows collection from its parent."
Which is not the same, as it will fall into the "Otherwise" if
`index == -1` and the rows collection is empty and try and get the -2nd
element of the rows.
Found with Domato.
Step 1 of the spec is to capture the <script> element's node document
into a local variable.
When I originally implemented this, I thought this was not necessary.
However, I realised that the script that runs can adopt the current
script element into a different document, meaning step 5.4 and 6 then
operate on the incorrect document.
Covered by this WPT: 7b0ebaccc6/html/semantics/scripting-1/the-script-element/moving-between-documents-during-evaluation.html
Previously, we would use lossy strtod() conversion. This was bad,
especially since we switched from internally storing Calculator
state in a double to storing it in the KeypadValue class
some time ago. This commit adds a constructor for the KeypadValue
class that is not lossy by using strtoll(). It handles numbers
with and without decimal points as well as negative numbers
correctly.