I've only just realised that there's a false-positive bug in the latin.c solver framework. It's designed to solve puzzles in which the solution is a latin square but with some additional constraints provided by the individual puzzle, and so during solving, it runs a mixture of its own standard deduction functions that apply to any latin-square puzzle and extra functions provided by the client puzzle to do deductions based on the extra clues or constraints. But what happens if the _last_ move in the solving process is performed by one of the latin.c built-in methods, and it causes a violation of the client puzzle's extra constraints? Nothing will ever notice, and so the solver will report that the puzzle has a solution when it actually has none. An example is the Group game id 12i:m12b9a1zd9i6d10c3y2l11q4r . This was reported by 'groupsolver -g' as being ambiguous. But if you look at the two 'solutions' reported in the verbose diagnostics, one of them is arrant nonsense: it has no identity element at all, and therefore, it fails associativity all over the place. Actually that puzzle _does_ have a unique solution. This bug has been around for ages, and nobody has reported a problem. For recursive solving, that's not much of a surprise, because it would cause a spurious accusation of ambiguity, so that at generation time some valid puzzles would be wrongly discarded, and you'd never see them. But at non-recursive levels, I can't see a reason why this bug _couldn't_ have led one of the games to present an actually impossible puzzle believing it to be soluble. Possibly this never came up because the other clients of latin.c are more forgiving of this error in some way. For example, they might all be very likely to use their extra clues early in the solving process, so that the requirements are already baked in by the time the final grid square is filled. I don't know! Anyway. The fix is to introduce last-minute client-side validation: whenever the centralised latin_solver thinks it's come up with a filled grid, it should present it to a puzzle-specific validator function and check that it's _really_ a legal solution. This commit does the plumbing for all of that: it introduces the new validator function as one of the many parameters to latin_solver, and arranges to call it in an appropriate way during the solving process. But all the per-puzzle validation functions are empty, for the moment.
This is the main bulk of this boolification work, but although it's making the largest actual change, it should also be the least disruptive to anyone interacting with this code base downstream of me, because it doesn't modify any interface between modules: all the inter-module APIs were updated one by one in the previous commits. This just cleans up the code within each individual source file to use bool in place of int where I think that makes things clearer.
This commit removes the old #defines of TRUE and FALSE from puzzles.h, and does a mechanical search-and-replace throughout the code to replace them with the C99 standard lowercase spellings.
latin_check now returns bool, and latin_solver_diff_set takes a bool 'extreme' flag. Should be non-disruptive.
Oops! This was left over from an early development version of commits 4408476b7 and 000ebc507, in which I initially arranged for each adjacency list to be terminated with the sentinel value -1 instead of separately storing an array of the lists' lengths. I later changed the representation to make randomising the algorithm easier (it's much easier to shuffle an array uniformly at random if you _don't_ have to faff endlessly to work out its length). But this write of a no-longer- needed sentinel value in the client code must have survived the rewrite by mistake, and also somehow evaded all my pre-commit testing with valgrind and asan. A user reported that the Towers Javascript version was crashing on startup, and I think this is the cause, because it seems to fix it for me.
The new client code is a lot smaller and nicer, because we can throw away the col[] and num[] permutations entirely. Of course, this also means that every puzzle that incorporated latin.c now has to link against matching.c instead of maxflow.c - but since I centralised that secondary dependency into Recipe a few commits ago, it's trivial to switch them all over at once.
In solver_show_working mode, we were logging all the deductions, guesswork and backtracking, but not printing out the actual solution (if any) reached at the end of each branch of the tree.
I've also added that warning option and -Werror to the build script, so that I'll find out if I break this property in future.
Hitori. One infrastructure change in the process: latin.c has acquired a utility function to generate a latin rectangle rather than a full square. [originally from svn r8828]
introduced to mimic similar macros in solo.c, in case Solo ever moved over to being based on the latin.c solver framework; but even Solo has long since lost those macros, so latin.c has no need to keep them. [originally from svn r8827]