chiark / gitweb /
Forbid undo-of-new-game after midend_set_config.
authorSimon Tatham <anakin@pobox.com>
Sat, 9 Dec 2017 21:28:41 +0000 (21:28 +0000)
committerSimon Tatham <anakin@pobox.com>
Sat, 9 Dec 2017 21:28:41 +0000 (21:28 +0000)
commit5247edd16dac8f673a03619e1aae76bf10f8eb43
treee88eab20bd810e5510406dfef47dc72eb7cbab20
parent4f8a4f7d7fb44e978b629c825ec871c7708e87b8
Forbid undo-of-new-game after midend_set_config.

This is another situation in which the midend's state, at the time
midend_new_game tries to save it, is not such as to generate a viable
serialisation. In this case, it's because after the user enters a game
id into the Game > Specific or Game > Random Seed dialog box,
midend_set_config will have _already_ started overwriting important
fields of the midend such as me->desc and me->seed, before
midend_new_game is even entered.

In fact this caused an assertion failure (thanks to Lennard Sprong for
reporting it), because one of those fields was set to NULL, so the
resulting serialisation buffer was incomplete, leading to a
deserialisation error later. But I was lucky: if I hadn't been, the
serialisation might have been complete, and valid according to the
deserialisation code, but would have contained a mixture of the new
game's description and the old one's move chain, which would surely
have had far stranger results.

For the moment, I'm fixing this by simply not storing a serialisation
in that situation. Perhaps a nicer approach might be to store one
before starting to overwrite midend fields, and then have
midend_new_game swap it in if it's already been generated. That way
you _could_ still undo past an action like this. But preventing the
assertion failure is a good start.
midend.c