simon-git: puzzles (main): Ben Harris

[Commits to Tartarus hosted VCS]

TL;DR:
  93be3f7 Be more careful with type of left operand of <<
  e2d390a Map: reduce maximum size
  6ee62a4 Correctly handle some short save files

Repository:     https://git.tartarus.org/simon/puzzles.git
On the web:     https://git.tartarus.org/?p=simon/puzzles.git
Branch updated: main
Committer:      Ben Harris <bjh21 at bjh21.me.uk>
Date:           2023-02-26 22:49:08

commit 93be3f7ccaa63b0fd953bcfd88d685b47b76605e
web diff https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=93be3f7ccaa63b0fd953bcfd88d685b47b76605e;hp=9dbcfa765ba59a8201425df18bec09c7bc334c5e
Author: Ben Harris <bjh21 at bjh21.me.uk>
Date:   Sun Feb 26 14:24:38 2023 +0000

    Be more careful with type of left operand of <<
    
    On a 32-bit system, evaluating 1<<31 causes undefined behaviour because
    1 is signed and so it produces signed overflow.  UBSan has spotted a
    couple of occasions where this happens in Puzzles, so in each case I've
    converted the left operand to the unsigned result type we actually want.

 cube.c   | 4 ++--
 random.c | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

commit e2d390aae872cee4cb16d746af3b2eeb7713cbf5
web diff https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=e2d390aae872cee4cb16d746af3b2eeb7713cbf5;hp=93be3f7ccaa63b0fd953bcfd88d685b47b76605e
Author: Ben Harris <bjh21 at bjh21.me.uk>
Date:   Sun Feb 26 14:51:09 2023 +0000

    Map: reduce maximum size
    
    validate_desc relies on being able to calculate 2*wh in an int, so the
    maximum grid size is at most INT_MAX/2.

 map.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

commit 6ee62a43abe7d7e77226415b21d1cbf16dbda85a
web diff https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=6ee62a43abe7d7e77226415b21d1cbf16dbda85a;hp=e2d390aae872cee4cb16d746af3b2eeb7713cbf5
Author: Ben Harris <bjh21 at bjh21.me.uk>
Date:   Sun Feb 26 21:48:10 2023 +0000

    Correctly handle some short save files
    
    A save file that ended in the middle of a value before the "SAVEFILE"
    field had been loaded would cause a read from uninitialised memory.
    While technically undefined behaviour this was practically pretty
    harmless.  Fixed by handling unexpected EOF here the same an
    unexpected EOF anywhere else.
    
    This bug could be demonstrated by loading a truncated save file like
    this in a build with MemorySanitizer enabled:
    
    SAVEFILE:41:Simo

 midend.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)