KaiOS (which is based on Firefox OS, formerly Boot to Gecko) runs its
"native" apps in a Web browser, so this is essentially a rather
specialised version of the JavaScript front-end. Indeed, the JavaScript
and C parts are the same as the Web version.
There are three major parts that are specific to the KaiOS build.
First, there's manifest.pl, which generates a KaiOS-specific JSON
manifest describing each puzzle.
Second, there's a new HTML page generator, apppage.pl, that generates an
HTML page that is much less like a Web page, and much more like an
application, than the one generated by jspage.pl. It expects to build a
single HTML page at a time and gets all its limited knowledge of the
environment from its command line. This makes it gratuitously different
from jspage.pl and javapage.pl, but makes it easier to run from the
build system.
And finally, there's the CMake glue that assembles the necessary parts
for each application in a directory. This includes the manifest, the
HTML, the JavaScript, the KaiOS-specific icons (generated as part of the
GTK build) and a copy of the HTML documentation. The directory is
assembled using CMake's install() function, and can be installed on a
KaiOS device using the developer tools.
These are built alongside other icons as part of the GTK build. It
builds new icon sizes of 44 and 88 pixels and then uses ImageMagick to
round off the corners and add a shadow in accordance with the KaiOS
design guide.
Since using the "solve" option doesn't consume a guess, it's safe to
allow it to occur multiple times. Without this, selecting "solve" a
second time causes an assertion failure because solve() returns a move
string that's rejected by execute_move().
Possible solve() could instead refuse to solve an already-solved
puzzle, but that seems needlessly pedantic.
[fixes c84af670b52f09e9e47587584c0559c508d4a37d]
Chris mentioned in the commit message that there was a risk that
illegal moves might be permitted when playing on after a solve. So
I've changed the condition so that it depends only on whether the move
_currently being executed_ is a solve, rather than whether there was a
solve action anywhere in the undo history.
(Also, wrapped overlong lines while I was here.)
Not only does it set the outer edges to NOTRACK, but it may also overwrite
any mistakes the user has previously made elsewhere. Otherwise, the entire
solve is rejected ("Solve unavailable" error on Android) if the user has
made a single mistake, which is inconsistent with the other games.
This may be giving a free pass to corrupted moves that occur after a solve,
so this may still want tightening up in some way, but it's still limited to
squares within the grid, so I agree with Ben's assessment that this is
likely not to be exploitable.
Fixes#584
(cherry picked from Android port, commit
33bd14fb6f7cd760e7218fffd90f3a266b1f4123)
If I re-run cmake in a Unix build directory, it unconditionally
rewrites generated-games.h, which causes fuzzpuzz to be rebuilt. This
is a waste of effort in the extremely common case where the rewritten
generated-games.h is identical to the old one.
Now we write the data to a temporary file first, and use cmake's
'configure_file' command to copy that to generated-games.h, because it
so happens that configure_file checks if the two files are identical
and avoids updating the timestamp on the destination file if so.
(This will presumably also be a beneficial change on any other
platform that uses generated_games.h in the build, such as OS X. I
just hadn't noticed until it hit the build I most often re-run in an
existing build directory.)
cmake 3.21 has a more intuitively spelled command I could have used,
called 'file(COPY_FILE src dst ONLY_IF_DIFFERENT)'. But we currently
permit cmake all the way back to 3.5, so I can't use that.
When reporting that the game name in a save file isn't recognised,
don't include the name from the save file in the error message, partly
to avoid the complexity of freeing it properly on two different code
paths and partly because including unsanitized data from a
fuzzer-supplied save file in the error message just seems dangerous.
And properly sanitising it would waste the fuzzer's time exploring the
sanitising code.
Thanks to Ben Hutchings for reporting the bug.
Tracks allowed moves in execute_move() that shouldn't have been allowed,
like changing the state of the edges of the board. This moves couldn't
be generated by interpret_move(), but could be loaded from a save file.
Now execute_move() uses the same ui_can_flip_*() functions as
interpret_move() to decide whether a particular move is allowed. This
should prevent some assertion failures when loading corrupted save
files.
Towers' new_game() causes an assertion failure on game description
strings that contain spurious characters after a valid description, so
validate_desc() should also refuse such a description. The problem
could be demonstrated by editing the game description in the
"Specific" dialogue box to add a '!' at the end, which caused
"new_game: Assertion `!*p' failed.".
If a Mines save file contains a move after the player has already
died, this can lead to an assertion failure once there are more mines
that covered squares. Better to just reject any move after the
player's died.
It allowed V, W, X, Y, H, I, J, and K to appear in game descriptions
even though new_game() didn't ascribe any meaning to those letters and
would fail an assertion if they ever occurred. As far as I can tell,
those letters have never done anything, so I've just removed the
checks for them from validate_desc().
Without this, execute_move() can end up reading off the end of the
move string, which isn't very friendly. Also remove the comment
saying that the move string doesn't have to be null-terminated,
because now it does.
It can't signal an error, but it's worth documenting that it can
receive invalid input and should do what it can with it. I assume
that failing to decode game_ui data from a newer version generally
won't be disastrous the way failing to decode a description or move
string would be.
Previously if a move string starting with "M" contained anything else
other than a digit or a comma, execute_move() would spin trying to
parse it. Now it returns NULL.
Other games tolerate receiving an encoded game_ui even if they can
never generate one. This is sensible, since it means that if a new
version starts saving UI state, old versions can load save files
generated by those newer versions.
This makes sure that width * height <= INT_MAX, which it rather needs
to be. Also a similar check in decode_params when defaulting the
number of mines.
This makes sure that width * height <= INT_MAX, which it rather needs
to be. Also a similar check in decode_params when defaulting the
number of regions.
Every grid shape has its own limit, so this involved adding a new
interface between loopy.c and grid.c. The limits are based on ensuring
that the co-ordinate system of the grid doesn't overflow INT_MAX and
neither do the lengths of the face and dot arrays.
Though now I come to look at it I think the actual limits of grid.c are
much lower. Hmm.
