How do you understand cryptic code?

[honey the codewitch]

I have only one thing to say in response, but it's a mouthful:

static int stbtt__run_charstring(const stbtt_fontinfo *info, int glyph_index, stbtt__csctx *c)
{
int in_header = 1, maskbits = 0, subr_stack_height = 0, sp = 0, v, i, b0;
int has_subrs = 0, clear_stack;
float s[48];
stbtt__buf subr_stack[10], subrs = info->subrs, b;
float f;

#define STBTT__CSERR(s) (0)

// this currently ignores the initial width value, which isn't needed if we have hmtx
b = stbtt__cff_index_get(info->charstrings, glyph_index);
while (b.cursor < b.size) {
i = 0;
clear_stack = 1;
b0 = stbtt__buf_get8(&b);
switch (b0) {
// @TODO implement hinting
case 0x13: // hintmask
case 0x14: // cntrmask
if (in_header)
maskbits += (sp / 2); // implicit "vstem"
in_header = 0;
stbtt__buf_skip(&b, (maskbits + 7) / 8);
break;

  case 0x01: // hstem
  case 0x03: // vstem
  case 0x12: // hstemhm
  case 0x17: // vstemhm
     maskbits += (sp / 2);
     break;

  case 0x15: // rmoveto
     in\_header = 0;
     if (sp < 2) return STBTT\_\_CSERR("rmoveto stack");
     stbtt\_\_csctx\_rmove\_to(c, s\[sp-2\], s\[sp-1\]);
     break;
  case 0x04: // vmoveto
     in\_header = 0;
     if (sp < 1) return STBTT\_\_CSERR("vmoveto stack");
     stbtt\_\_csctx\_rmove\_to(c, 0, s\[sp-1\]);
     break;
  case 0x16: // hmoveto
     in\_header = 0;
     if (sp < 1) return STBTT\_\_CSERR("hmoveto stack");
     stbtt\_\_csctx\_rmove\_to(c, s\[sp-1\], 0);
     break;

  case 0x05: // rlineto
     if (sp < 2) return STBTT\_\_CSERR("rlineto stack");
     for (; i + 1 < sp; i += 2)
        stbtt\_\_csctx\_rline\_to(c, s\[i\], s\[i+1\]);
     break;

  // hlineto/vlineto and vhcurveto/hvcurveto alternate horizontal and vertical
  // starting from a different place.

  case 0x07: // vlineto
     if (sp < 1) return STBTT\_\_CSERR("vlineto stack");
     goto vlineto;
  case 0x06: // hlineto
     if (sp < 1) return STBTT\_\_CSERR("hlineto stack");
     for (;;) {
        if (i >= sp) break;
        stbtt\_\_csctx\_rline\_to(c, s\[i\], 0);
        i++;
  vlineto:
        if (i >= sp) break;
        stbtt\_\_csctx\_rline\_to(c, 0, s\[i\]);
        i++;
     }
     break;

  case 0x1F: // hvcurveto
     if (sp < 4) return STBTT\_\_CSERR("hvcurveto stack");

[Julian Ragan]

I either write code analysis report, where I divide code into sections and write section by section, what I think it does, then verify with debugger, or I create a good old flow diagram, if it is really cryptic (even for OO this will work for extracting actual algorithms, if you can identify sequence first).

[honey the codewitch]

I can totally see the sense in that, but I could never do it. Too rigorous for me. :laugh: I am good at improvisation and creativity, but I am no good at being methodical.

Real programmers use butterflies

[JP Reyes]

Not exactly. I used to use C to spit out ARM16 Assembler so I got an idea how I could program what I needed in assembler...then I yanked out all the stuff I didn't need (Like when you throw out all the useless HTML an editor generates). Smaller, faster, optimized and straight to the point (well for me...anybody else would also have to be comfortable with ARM16 as well)

[englebart]

Do you port all pointers to array access? Pointers are always the pain for this type of exercise. Some algorithms are easier to understand that way. Multilevel pointers are the worst.

[honey the codewitch]

Whenever I can, that's what I do. I turn it to arrays and indices. It is difficult but actually that process is critical for me to understand it. It's one of the most important parts of the port. And yeah, double indirection and such gets tricky fast.

Real programmers use butterflies

[honey the codewitch]

I rarely write in assembly these days but I read it a lot. I've focused more on getting C and particularly C++ to generate the exact machine code I intended if I'd have written by hand, or as is often the case, better.

Real programmers use butterflies

[Julian Ragan]

Yeah, it is exhausting to do in a complex code base.

[NightPen]

Start by determining what data it works with. Then split out the functions and start figuring out the inputs and outputs from each function. Finally, make a process and data flow diagrams for the code. This process makes short work of understanding even the most cryptic code. If you don't want to spend a day or two doing this process there are tools like sourcetrail that will do the work for you.

[hur10forcer10]

If the project is fairly significant in size with multiple .c and .h files with many functions, I will often turn doxygen (with graphviz) loose on it. Even though the code may not have any doxygen tags or doxygen-compatible comment blocks to generate function and API documentation, it can still give you an idea of "what calls what" in a graphical context.