ref: d60e348aae16e718e1e7cc2b6e090956eb7e4b52
parent: ffe8639619dbccd838c5b226f84d4cf0eb99b69d
author: Simon Tatham <anakin@pobox.com>
date: Tue Nov 3 01:56:47 EST 2015
Format Palisade solve-type moves in sensible ASCII. The solve move stored in 'aux' by new_game_desc consists of printable characters in the range '@' to 'O', each representing a 4-bit bitmap of edges around a cell. But the one generated on the fly by solve_game() was missing out the 0x40 bit and just returning characters in the range ^@ to ^O - which would not only have been horrible if you found such a string in a save file, but also meant that a game with any completely borderless square would have a solution move string terminating early due to the ^@, causing execute_move() to reject it. Example: ./palisade --test-solve --generate 1 5x5n5#12345-37 now succeeds, where previously it failed an assertion.
--- a/palisade.c
+++ b/palisade.c
@@ -755,8 +755,12 @@
init_borders(w, h, move + 1);
move[wh + 1] = '\0';
- if (solver(&state->shared->params, state->shared->clues, move + 1))
+ if (solver(&state->shared->params, state->shared->clues, move + 1)) {+ int i;
+ for (i = 0; i < wh; i++)
+ move[i+1] |= '@'; /* turn into sensible ASCII */
return (char *) move;
+ }
*error = "Sorry, I can't solve this puzzle";
sfree(move);