Brutkey

Per Vognsen
@pervognsen@mastodon.social

@blackeggs@infosec.exchange The point is that you're dealing with a general tree-like structure just to represent a single node in a persistence-friendly way, i.e. you're essentially composing multiple persistent data structures and you should probably express your code in that way, and for that part you need balanced or radix trees or something like that.

mistymntncop
@blackeggs@infosec.exchange

@pervognsen@mastodon.social

RADDBG uses hierarchical string trees for storing upstream Config state (the master state where more fine-grained state is computed) and they use LCRS trees. This had me wondering how you would actually make such a data structure persistent. If you have persistency then you trivially have undo/redo I believe.

https://github.com/EpicGamesExt/raddebugger/blob/e1d6b9f3196693160dce5664e321c028b8a74aa9/src/raddbg/raddbg_core.h#L274

Per Vognsen
@pervognsen@mastodon.social

@blackeggs@infosec.exchange Persistent trees are way too much overhead compared to an undo log, though, if you can't make use of any of their other advantages.

Per Vognsen
@pervognsen@mastodon.social

@blackeggs@infosec.exchange An easy way to implement any data structure like this is to implement the memory itself semi-persistently. That is, you have a semi-persistent abstract data type which is called a memory. It implements read_uint16, write_uint32, copy_bytes, undo, redo, etc, and it keeps an undo/redo log of what it overwrites and at what offset so you can undo/redo it later.

mistymntncop
@blackeggs@infosec.exchange

@pervognsen@mastodon.social Ahh a history of diffs I think is what you mean.