From d60e348aae16e718e1e7cc2b6e090956eb7e4b52 Mon Sep 17 00:00:00 2001 From: Simon Tatham Date: Tue, 3 Nov 2015 06:56:47 +0000 Subject: [PATCH] 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. --- palisade.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/palisade.c b/palisade.c index 8776cc1..f7b3791 100644 --- a/palisade.c +++ b/palisade.c @@ -755,8 +755,12 @@ static char *solve_game(const game_state *state, const game_state *currstate, 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);