25 submissions, 24 compiled, 552 games ran. Fastest game 2 msec, lower quartile 221 msec, median 860 msec, mean 2.35 sec, upper quartile 2.36 sec, slowest game 45.40 sec. The graph looks very similar; as I'd expect, not much performance improvement shows up in the morning round.

The sole compile failure was very interesting: Clang's automatic static and semantic analysis beats the mouldering pile of cruft that is GCC. As you've probably noticed, since round00c, we've used the same `3c` compiler shim that inserts AddressSanitizer and UndefinedBehaviourSanitizer, but because its architecture is radically different to GCC, it's a lot more capable of picking up compile errors.

GameView.c:690:15: error: variable 'specialID' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized]
   } else if (location[0] == 'T'){
              ^~~~~~~~~~~~~~~~~~
GameView.c:693:11: note: uninitialized use occurs here
   return specialID;
          ^~~~~~~~~
GameView.c:690:11: note: remove the 'if' if its condition is always true
   } else if (location[0] == 'T'){
          ^~~~~~~~~~~~~~~~~~~~~~~
GameView.c:673:17: note: initialize the variable 'specialID' to silence this warning
   int specialID;
                ^
                 = 0
1 error generated.

Control flow analysis is actually a very interesting digraph problem. Each "basic block" forms a node, and each conditional creates edges linking other blocks together. It's not undirected -- control flow can't suddenly go backwards -- and it's not acyclic, because control flow is allowed to loop.

On the topic of AddressSanitizer, there was a great question on the forums by Brian Do:

What does the address sanitizer do and why does it pick up stuff that valgrind doesn't? I copied the dryrun tests and ran it under valgrind and it doesn't detect any errors, but the address sanitizer does.

The AddressSanitizer is a memory error checker. It detects use after free/return/scope, heap/stack/global buffer under/overflows, initialization order bugs, and memory leaks. If you've used dcc before, that's what does its memory error management.

Valgrind takes any executable, and instead of running it on the machine directly, it has a great big switch statement in it that interprets each instruction, checks it, and then runs it. Along the way, it replaces calls to a few types of function,s including memory allocation and memory and string manipulation functions, with its own book-keeping versions of them.

The AddressSanitizer, by comparison, uses a very different approach: it must be compiled into a program (which is why the binaries produced when you compile with ASan or dcc are ~1.5 MB, and without them are tens of kilobytes), and it slots into the compiler's code generation pass: it also replaces memory allocator and some string/memory functions, but also inserts function calls to check against its shadow memory, a bit-mask of what memory is accessible and why. On memory errors, you'll see a dump of the shadow memory around what you tried to access. (If you're interested, there's much more excruciating detail on the Sanitizers wiki < https://github.com/google/sanitizers/wiki >.)

Because ASan has a quite different algorithm, a fairly different approach, and is under very active development (by Google, who use it to whack memory bugs in Chrome) you'll often find it picks up a very different set of bugs to Valgrind. The flip-side is that ASan is necessarily invasive: it uses a significant amount more memory and increases executable size.

I (personally) tend to trust ASan more, mainly out of familiarity. For the dryruns, I've hooked up ASan as a back-stop; most of the memory errors you could make would be detected by Valgrind, but a small number aren't. If you run into one of those cases, I'm happy to take a look.

So, inspired by that, I went and scraped the logs for memory errors being reported by AddressSanitizer... uh oh.

 6   SUMMARY: AddressSanitizer: FPE dracula.c:28:52 in decideDraculaMove
 1   SUMMARY: AddressSanitizer: FPE dracula.c:98:30 in decideDraculaMove
13   SUMMARY: AddressSanitizer: heap-buffer-overflow dracula.c:55:20 in decideDraculaMove
41   SUMMARY: AddressSanitizer: heap-buffer-overflow dracula.c:60:33 in decideDraculaMove
 6   SUMMARY: AddressSanitizer: undefined-behavior dracula.c:28:52 in 
 1   SUMMARY: AddressSanitizer: undefined-behavior dracula.c:68:19 in 
 1   SUMMARY: AddressSanitizer: undefined-behavior dracula.c:98:30 in 
 1   SUMMARY: AddressSanitizer: undefined-behavior DracView.c:288:16 in 
 1   SUMMARY: AddressSanitizer: undefined-behavior DracView.c:292:16 in

I'm impressed by the number of actual issues we're picking up, notably buffer overflows and actual crashes. I haven't seen any leaks reported, though, so I guess there's that.

I'll be putting together something to view rank change over time later today, hopefully. Next round is at 20:03 tonight.