This fixes the issue with the exported data having a leading zero,
causing RSA::encrypt to trim the block down, and ruining the encryption.
Fixes#2691 :^)
Some of the remaining instructions have different behavior for
register and non-register ops. Since we already have the
two-level flags tables, model this by setting all handlers in
the two-level table to the register op handler, while the
first-level flags table stores the action for the non-reg handler.
Now that we don't keep a C compiler around in the toolchain (to save
space) we can't have .c files in the build.
This reminds me that #362 exists and we should fix that at some point.
Const pointers into the DOM was a nice idea, but in practice, there are
too many situations where the layout tree wants to some non-const thing
to the DOM.
ModularFunctions::random_number calls into AK::fill_with_random calls (on
Serenity) into arc4random_buf calls into Process::sys calls into
get_good_random_bytes, which is cryptographically secure.
Some of these don't just use the REG bits of the mod/rm byte
as slashes, but also the R/M bits to have up to 9 different
instructions per opcode/slash combination (1 opcode requires
that MOD is != 11, the other 8 have MODE == 11).
This is done by making the slashes table two levels deep for
these cases.
Some of this is cosmetic (e.g "FST st0" has no effect already,
but its bit pattern gets disassembled as "FNOP"), but for
most uses it isn't.
FSTENV and FSTCW have an extraordinary 0x9b prefix. This is
not yet handled in this patch.
It doesn't make sense for a top-level menu to have an icon, however
we do not have dedicated classes to distinguish these.
Furthermore, the only other place to store an icon is MenuItem.
Storing it there would be highly confusing, as MenuItem-with-Action
then would have two icons: one in Action and one in MenuItem.
And because we need to be able to replace the icon during realization,
this would need to write-through to Action somehow.
That's why I went with Menu, not MenuItem.
This factors out icon realization into its own function, making it possible to
use the same code with other classes that have icon() and set_icon() methods.
Moves ProcessChooser and RunningProcessesModel to LibGUI and
generalizes their construction for use by other apps. Updates
Profiler to reflect the change and use its new icons.
"0" was interpreted as a base-8 prefix, and the parse pointer was then
unconditionally advanced, causing us to consume zero characters.
This unbreaks the git port. :^)
(We should really have tests for LibC..)
This being inline somehow broke the binutils autoconf scripts. It used
to work, so I suspect that some other change to LibC has caused those
autoconf scripts to go down a new path.
Regardless, this seems perfectly sensible.
Note that these aren't full implementations of the bindings. This
mostly implements the low hanging fruit (namely, basic reflections)
There are some attributes that should be USVString instead of
DOMString. However, USVString is a slightly different definition
of DOMString, so it should suffice for now.
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. :^)
\x consumes all hex digits following it. (If the resulting number
then doesn't fit in the character type, the compiler emits an
error.)
\x would be much more convenient to use if it was always followed
by exactly two hex digits (with \u and \U for higher codepoints),
but that's sadly not the world we live in.
