Post B4YXy4UTIPhylh42BU by cgnarne@hj.9fs.net
 (DIR) More posts by cgnarne@hj.9fs.net
 (DIR) Post #B4YXy3lRznhCW4050i by pixx@merveilles.town
       0 likes, 0 repeats
       
       Working on an old abandoned code base where i can't talk to the authors and it takes hours to figure out some of the bullshit it's pulling off, i can definitely see the appeal for a tool that can quickly read over the code and check my inferences on e.g. memory flow and ownership patternsNowadays, people would obviously default to either LLMs for that or for arguing that humans should do it because the other people are saying LLMs and fuck thatBut what I'm more interested in: there's plenty of static analysis tools for checking code you wrote. Is there any prior art in deterministic static analysis tools that help _read code_ by other people?Dataflow and control flow analysis are super commonly used in compiler optimization. Are there any tools out there that do dataflow analysis and then, say, can look at a variable and show all _possible references_ and relevant code?E.g. this Foo* is passed to foo(), so it can be f there, which might call bar, and ...)Or "this code allocates Bar, here's the entire possible relevant code for what might happen to that across this 100kloc project, here's every function in every file that might use _that specific value_, and an explanation of how it gets there"
       
 (DIR) Post #B4YXy3xrFfcX8XnzLk by pixx@merveilles.town
       0 likes, 0 repeats
       
       Something fascinating here: this is a codebase in C. It's not doing anything crazy by the rules of C. C is my preferred language, the one I'm best at. I understand every single line of code, on its own.But a lot of the high level logic feels weirdly foreign, moreso than typical Go code even.I can read the code and go "oh that's a hash table" pretty easily, and i get using a hash table to quickly identify cached blocksBut the table is, implicit? Sorta?The heads of each "bucket" are stored in the cache, but there's no real bucket. Each block just has a doubly linked list to follow prev/next pointers which, sure, but then it also multiple other unrelated lists.Okay, not too crazy.But they're sorted by a fake ticker clock, except not entirely, only sorta quadratically? Which seems to just be a way to maintain a LRU in *yet another list* sorting the *exact same set* of *statically allocated blocks*.And, i can untangle all of this. It requires pen and paper ( or a .tex file), but it's a fascinating experience reading something, understanding what it means, but having no clue what it's doing
       
 (DIR) Post #B4YXy4FwAS5A2cGQWu by pixx@merveilles.town
       0 likes, 0 repeats
       
       What i mean is, it's kinda weird that even something as well defined as C can change so much in 20 years as to require basically relearning the idioms.It's also... kinda just an argument that this code is bad, tbh. Lots of Plan 9 code is this old, much of it uses similar patterns, little of it has ever taken me this much effort to reverse engineer...
       
 (DIR) Post #B4YXy4UTIPhylh42BU by cgnarne@hj.9fs.net
       0 likes, 0 repeats
       
       @pixx@merveilles.town the plan9 code base is pretty good. but there are some turds in the punchbowl.