so I'm debugging this C code. it is ... let's say "quirky". We read a large binary blob and decode / deserialize it into a tree structure Each node is run length encoded, so we use an obscure x86 opcode that's bubbled up to a C function to tell us how many "1" bits are set...
-
Show this thread
-
2/ once we know the number of "1" bits we can, through some hand waving, figure out how long the following data is, and read that. We read that, decode it, and store it as a node of the tree. Except the nodes of the tree are stored in a multi-level hash table. That ALSO >>>
1 reply 0 retweets 7 likesShow this thread -
3/ uses the number of 1 bits in a number to perform a certain optimization. How are nodes of the hashtable (which we use to store nodes of the tree) allocated? Glad you asked. Via a custom memory allocator that manages both heap and stack. Well that's not so bad is it?
3 replies 0 retweets 8 likesShow this thread -
4/ well, actually, it sort of is. The memory allocator - for obscure reasons that can best be explained as "premature optimization is the root of all evil" - can flip between different 'eras' or scopes, and when it does, the stack and the heap switch directions.
2 replies 1 retweet 14 likesShow this thread -
5/ so, at least this is all well documented, right? no there are no comments. except occasionally things like "this is very obscure and bad, but we have to keep it" 100% serious
2 replies 2 retweets 14 likesShow this thread -
6/ well, at least you can deduce what's going on from function names, right? no the functions are all named after obscure literature or puns and so forth
5 replies 0 retweets 20 likesShow this thread -
Replying to @MorlockP
"you must have read this __/---- many old books to understand this code"
1 reply 1 retweet 5 likes
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.