## TODO ~~TODO: Reader::next_n should return the number of items read as Err(ReadError::Incomplete(n)) if the buffer is exhausted~~ * a reader's `.offset()` should reflect the amount of items that were consumed, if any. if a reader can quickly determine there is not enough input, should it return Incomplete(0) or ExhaustedInput? Incomplete(0) vs ExhaustedInput may still imply that some state was changed (an access mode, for example). this needs more thought. TODO: Reader::offset should return an AddressDiff
, not a bare Address * quick look seems reasonable enough, should be changed in concert with yaxpeax-core though and that's more than i'm signing up for today TODO: impls of `fn one` and `fn zero` so downstream users don't have to import num_traits directly * seems nice at first but this means that there are conflicting functions when Zero or One are in scope ... assuming that the idea at the time was to add `fn one` and `fn zero` to `AddressBase`. TODO: 0.4.0 or later: * remove `mod colors`, crossterm dependency, related feature flags ## 0.3.1 fix InstructionTextSink::write_char to not panic in debug builds ## 0.3.0 added a new crate feature flag, `alloc`. this flag is for any features that do not require std, but do require containers from `liballoc`. good examples are `alloc::string::String` or `alloc::vec::Vec`. added `yaxpeax_arch::display::DisplaySink` after revisiting output colorization. `DisplaySink` is better suited for general markup, rather than being focused specifically on ANSI/console text coloring. `YaxColors` also simply does not style text in some unfortunate circumstances, such as when the console that needs to be styled is only written to after intermediate buffering. `DisplaySink` also includes specializable functions for writing text to an output, and the implementation for `alloc::string::String` takes advantage of this: writing through `impl DisplaySink for String` will often be substantially more performant than writing through `fmt::Write`. added `mod color_new`: this includes an alternate vision for `YaxColors` and better fits with the new `DisplaySink` machinery; ANSI-style text markup can be done through the new `yaxpeax_arch::color_new::ansi::AnsiDisplaySink`. this provides more flexibility than i'd initially expected! yours truly will be using this to render instructions with HTML spans (rather than ANSI sequences) to colorize dis.yaxpeax.net. in the future, `mod colored` will be removed, `mod color_new` will be renamed to `mod color`. deprecated `mod colored`: generally, colorization of text is a presentation issue; `trait Colorize` mixed formatting of data to text with how that text is presented, but that is at odds with the same text being presented in different ways for which colorization is not generic. for example, rendering an instruction as marked up HTML involves coloring in an entirely different way than rendering an instruction with ANSI sequences for a VT100-like terminal. added `yaxpeax_arch::safer_unchecked` to aid in testing use of unchecked methods these were originally added to improve yaxpeax-x86 testing: https://github.com/iximeow/yaxpeax-x86/pull/17, but are being pulled into yaxpeax-arch as they're generally applicable and overall wonderful tools. thank you again 522! added `mod testkit`: this module contains tools to validate the correctness of crates implementing `yaxpeax-arch` traits. these initial tools are focused on validating the correctness of functions that write to `DisplaySink`, especially that span management is correct. `yaxpeax-x86`, for example, will imminently have fuzz targets to use these types for its own validation. made VecSink's `records` private. instead of extracting records from the struct by accessing this field directly, call `VecSink::into_inner()`. made VecSink is now available through the `alloc` feature flag as well as `std`. meta: the major omission in this release is an architecture-agnostic way to format an instruction into a `DisplaySink`. i haven't been able to figure out quite the right shape for that! it is fully expected in the future, and will probably end up somehow referenced through `yaxpeax_arch::Arch`. ## 0.2.8 added an impl of `From