| Age | Commit message (Collapse) | Author |
|---|
|
|
|
be ... stern
|
|
if printed_size == 0 then the value must be 0, but we can check if the value is 0 before doing all that stuff
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
if mem_size is ever out of bounds thats a severe bug on its own
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
it turns out that yaxpeax-arch's notion of colorization has been broken from the start for systems that do markup without inline sequences (e.g. windows/cmd.exe before vt100 support)
|
|
`name()` returning a `[u8; 2]` is nice when there is a specializing and
unrolling write implementation, whereas `&str` might not consistently
unroll into a simple 2-byte copy (rather than loop). it'll look a little
more reasonable soon, hopefully..
|
|
|
|
|
|
write_2 will never actually be used, but im adapting it into contextualize in a... better way
|
|
the reasoning for *why* `visit_operand` is better here lives as doc
comments on `visit_operand` itself: it avoids going from scattered
operand details to `enum Operand` only to deconstruct the enum again.
instead, branch arms can get codegen'd directly against `struct
Instruction` layout.
|
