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.
This commit is contained in:
Simon Tatham
2024-08-01 08:49:40 +01:00
parent 62c0e0dcc9
commit 1c1899ee1c

View File

@ -17,7 +17,7 @@ in puzzles do perl -e 'print "\n\\versionid Simon Tatham'\''s Portable Puzzle Co
# Write out a version.h that contains the real version number.
in puzzles do echo '/* Generated by automated build script */' > version.h
in puzzles do echo '$#define VER "Version $(Version)"' >> version.h
in puzzles do perl -e '$$ARGV[0] =~ m{(....)(..)(..)} or die; print "$#define VERSIONINFO_BINARY_VERSION 1,$$1,$$2,$$3\n"' $(!builddate) >> version.h
in puzzles do perl -e '$$ARGV[0] =~ m{(....)(..)(..)} or die; ($$y,$$m,$$d)=($$1,$$2,$$3); $$m =~ s{^0*}{}; $$d =~ s{^0*}{}; print "$#define VERSIONINFO_BINARY_VERSION 1,$$y,$$m,$$d\n"' $(!builddate) >> version.h
# And do the same substitution in the OS X metadata. (This is a bit
# icky in principle because it presumes that my version numbers don't