simon-git: puzzles (main): Simon Tatham

Thu Aug 1 08:55:58 BST 2024

TL;DR:
  1c1899e Fix invalid integer literals in VERSIONINFO_BINARY_VERSION.

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:           2024-08-01 08:55:58

commit 1c1899ee1c4e0a83808998359addb1efb66322f8
web diff https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=1c1899ee1c4e0a83808998359addb1efb66322f8;hp=62c0e0dcc9e7e250f1936b107e5b76e881b69496
Author: Simon Tatham <anakin at pobox.com>
Date:   Thu Aug 1 08:49:40 2024 +0100

    Fix invalid integer literals in VERSIONINFO_BINARY_VERSION.

    Last November in commit 08365fb260ae6e3 I added a VERSIONINFO resource
    to the Windows puzzle binaries, with three of the four integer
    components of the binary version number taken from the year, month and
    day of the build date. The header file #define of those integers was
    made by a Perl one-liner which just split up $(!builddate) into the
    right groups of digits.

    But it didn't trim leading zeroes. So the build failed today because
    the month component of the version number was '08', which isn't a
    valid C integer literal (the leading 0 means octal, but 8 isn't an
    octal digit), and presumably therefore not valid according to llvm-rc
    either. I have to assume that the previous months have all worked
    because 01, ..., 07 _are_ valid octal integer literals and still mean
    the right things.

    I'm not 100% satisfied with this explanation, because surely the same
    argument applied to the day field should have meant my builds failed
    on the 8th and 9th of every month since I added this code last
    November! But I don't have any evidence left over to show why it
    _didn't_ fail. Perhaps I've upgraded llvm-rc past a relevant bug fix
    in the last month, or something.

 Buildscr | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)