Uploading the cache takes several minutes. This gives us a handy way to tell
which parts the worst culprits are.
The Toolchain cache seems to be the worst offender by far, because the binary
size nearly doubled when we upgraded from gcc9 to gcc10.
We were masking the fragment offset bits incorrectly in the IPv4 header
sent out with fragments. This worked up to ~32KB but after that, things
would get very confused. :^)
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.
I was a bit confused by the fact that a method named `build_system_menu()`
first enumerates a directory. Moving the app/category discovery to a dedicated
function that returns the GUI-relevant information makes this process a bit
less surprising.
As an added bonus, `g_app_category_menus` was actually only a temporary mapping,
and didn't need to be global. In theory, SystemMenu should use a handful fewer
of bytes now.
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.
We were accidentally calling memset() on "addr" (the input char*), not
"dst_addr" (the target struct sockaddr_in), which was causing a simple
"nc localhost 8000" to crash.
Fixes#2908.
"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.
