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...
-
-
8/ so anyway, my task is to change a certain data type from 32 bit to 64 bit except really, it's from 30 bit to 62 bit, because we use the top two bits to store metadata in a structure, or something, right? no, via bit twiddling
Show this thread -
9/ well, at least you can single step into the functions that do the bit twiddling and watch them work, right? no, it's all implemented via
#defines, so you can't single step into the multi-line "functions"Show this thread -
10/ well, at least you can rewrite the
#defines into functions so that you CAN single step through them, to see exactly where the memory corruption takes place, right? no why not?Show this thread -
11/ answer: let me circle back to that later ok, but at least you can use the types that functions return to help you understand the code, right? no, the code freely casts from type to type
Show this thread -
12/ well, you can look at those explicit casts and deduce something from them, right? no, the casts are implicit
Show this thread -
13/ well, at least you know that none of the implicit casts lose any significant bits, or mangles sign bits into data bits, or vice versa, right, because the compiler warns in those cases? no, because that compiler warning has been turned off
Show this thread -
15/ so, anyway, a few weeks later: * I've commented all of the code * I've renamed several funcs * I've rewritten macros as funcs * I've renamed variables * I've turned on compiler warnings * I've written funcs to do safe casts (or crash with error if values forbid it) >>>
Show this thread -
16/ ...and I've narrowed down a memory corruption issue to about a 5 line block. whew. Thank God this is F̶r̶i̶ whiskey-day
Show this thread -
17/ Anyway, gig is scheduled to run another ~4 weeks and I'm laying 50/50 odds that they won't renew me because I'm incompetent. ¯\_(ツ)_/¯
Show this thread -
18/ Oh, no, this isn't a "a Friday". This is "a most of May and all of June so far"https://twitter.com/ArthurFrDent/status/1137009727538249729 …
Show this thread -
19/ There was a certain mailing list I was on once, and then I left, and then some other guy joined, and read something about me and - not knowing that I'd been on the list - said "wow, look at this retard". He was corrected. >>>
Show this thread -
20/ "oh, no, Travis didn't retard himself into that situation. He GENIUSed his way into that situation."
Show this thread -
21/ Likewise, this code base. This is not the work of a retard. This is the work of a genius. The work of a retard can be discarded and replaced. The work of a genius needs to be tidied up by lesser craftsmen, who labor in obscurity. Michelangelo didn't spread his own tarps
Show this thread -
22/ Found the memory corruption issue. Old code: typedef uint32_t fred; typdef struct { fred a; fred b; } bob; new code: I replace uint32_t with uin64_t; sizeof(bob) automatically updates, right? no we're not doing sizeof(bob) ; we've got it hardcoded.
Show this thread - End of conversation
New conversation -
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.