simon-git: puzzles (main): Simon Tatham

[Commits to Tartarus hosted VCS]

TL;DR:
  5cac6a0 Black Box: reject negative ball counts in game_params.
  b907e27 Add validate_params bounds checks in a few more games.

Repository:     https://git.tartarus.org/simon/puzzles.git
On the web:     https://git.tartarus.org/?p=simon/puzzles.git
Branch updated: main
Committer:      Simon Tatham <anakin at pobox.com>
Date:           2023-01-22 16:12:02

commit 5cac6a09c4db2b7e05c3e8dfd8920e2cdd1b8b03
web diff https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=5cac6a09c4db2b7e05c3e8dfd8920e2cdd1b8b03;hp=806ae71ca45f913ebfd4aa18c8f0c80a67738a13
Author: Simon Tatham <anakin at pobox.com>
Date:   Sun Jan 22 08:54:06 2023 +0000

    Black Box: reject negative ball counts in game_params.
    
    You can inject one via a game desc string such as "10x10M5m-1", and
    it's clearly silly.
    
    _Zero_ balls, on the other hand, are a perfectly fine number: there's
    nothing incoherent about a BB puzzle in which the possible numbers of
    balls vary from (say) 0 to 5 inclusive, so that part of the challenge
    is to work out as efficiently as possible whether there are even any
    balls at all.
    
    (We only need to check minballs, because once we know minballs >= 0,
    the subsequent check ensures that maxballs >= minballs, and hence, by
    transitivity, maxballs >= 0 too.)

 blackbox.c | 2 ++
 1 file changed, 2 insertions(+)

commit b907e278751b740da7b9dc00c0cbdb93e7498919
web diff https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=b907e278751b740da7b9dc00c0cbdb93e7498919;hp=5cac6a09c4db2b7e05c3e8dfd8920e2cdd1b8b03
Author: Simon Tatham <anakin at pobox.com>
Date:   Sun Jan 22 09:30:57 2023 +0000

    Add validate_params bounds checks in a few more games.
    
    Ben tells me that his recent work in this area was entirely driven by
    fuzzing: he added bounds checks in validate_params when the fuzzer had
    managed to prove that the lack of them allowed something buggy to
    happen.
    
    It seemed worth doing an eyeball-review pass to complement that
    strategy, so in this commit I've gone through and added a few more
    checks that restrict the area of the grid to be less than INT_MAX.
    
    Notable in this commit: cube.c had to do something complicated because
    in the triangular-grid modes the area isn't calculated as easily as
    w*h, and Range's existing check that w+h-1 < SCHAR_MAX is sufficient
    to rule out w*h being overlarge _but_ should be done before w*h is
    ever computed.

 cube.c    | 24 ++++++++++++++++++++++++
 filling.c |  2 ++
 range.c   |  2 +-
 rect.c    |  2 ++
 slant.c   |  2 ++
 unruly.c  |  2 ++
 6 files changed, 33 insertions(+), 1 deletion(-)