Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
also update yaxpeax-arch to 0.2.4
|
|
|
|
also revise an `unsafe` that might be unsafe un extremely unlikely
circumstances - no one should be passing yaxpeax a `&[u8]` larger than
`isize::MAX`, but on 32-bit architectures we can't necessarily guarantee
that it won't happen
|
|
the previous test and code only tested one concrete archtecture, and it
turns out never required `std::error::Error` on `DecodeError`.
|
|
included is mandataing a `description` method on `DecodeError`
implementors - already approximately required by the Debug and Display
anyway.
also include a StandardPartialDecoderError for incomplete decoders to
use. i expect that one of the last steps of a decoder's 1.0 release will
be to move away from this.
|
|
|
|
|
|
this is useful for instruction sets like arm where instructions are
guaranteed to be 4 bytes, as well as instruction sets where an
instruction word is not a multiple of u8 bytes.
|
|
additional variants will require clients to implement DecodeError, still
|
|
|
|
|
|
|
|
|
|
on a feature that doesnt exist, no less!
|
|
addresses must implement a function that returns a struct that is
applicably formattable. particularly because the default Display impl on
primitives is not necessarily desirable, if you want hex. additionally
this allows meaningful Display for complex (eg, not a single primitive)
addresses, such as segmented memory
also expose AddressDisplay to name outside this crate. what an oversight
|
|
this makes yaxpeax-arch no_std. generally nothing has changed w.r.t
downstream crates, but a lot to do with colorization has been moved
tweaked to make it no_std-friendly (specifically, allowing `termion` to
be an optional dependency)
this also makes address parsing optional, in the hopes that decode-only
use cases don't need to involve as much machinery when building.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
through everything
|
|
|
|
|
|
|
|
|
|
enum to tie together a color and a thing to be colored, helper methods to build that, and an impl on Option that gives non-colored variants
|
|
or decimal strings
|
|
|
|
these traits are not ideal but are what i can do in rust right now
the initial attempt to add these traits involved a trait providing a
`colorize` function that returned a struct (or tuple) that impl'd
Display but bundled all useful data together. this would be nice because
use would be like:
```
println!("the next instruction is: {}", instr.colorize(settings));
```
but this runs into the same kind of lifetime issues as mentioned in the
ContextRead commit.
additionally complicating is contextualization, which involves a larger
structure than just a copyable color setting - a similar
builder-and-display style use would be nice but involves a third
lifetime (the content, the colors, the contexts) and is not workable.
references could be Rc pointers and this all might work. why not do
that?
moral opposition to cloning Rc pointers when doing any instruction
rendering. might be worth revisiting later if i'm convinced this is too
annoying - it's already close.
meanwhile, it turns out implementing traits on tuples is currently not
possible anyway - tuples are not #[fundamental].
in the future i need to investigate if i can use macros to tie into
`derive`, so that a ShowContextual impl can #[derive(Colorize,
Display)]. those implementations would really just call
ShowContextual.colorize with fewer and fewer parameters non-None.
the blanket impl
```
impl <T, U> Colorize for T where T: ShowContextual<U>
```
is entirely just a relic of one attempt, and can be ignored. this idea
conflicted with coherence rules because someone else could impl Colorize
for some type covered under this blanket impl.
|
|
|
|
|
|
instructions have a debug display
|
|
also add zero and one traits to Address, adjust layout
|
|
|