dholland [Sun, 8 Jan 2012 18:16:00 +0000 (18:16 +0000)]
Oops, I forgot to actually implement the checksumming code for the new
savefile format, so any savefiles generated yesterday can be tampered
with. Oh well. While here, tidy up the crc code.
dholland [Sat, 7 Jan 2012 22:23:16 +0000 (22:23 +0000)]
Redo save file handling. The old save files were unportable, had no
magic number or versioning, relied on random(3) never changing to a
different implementation, and were also saving pointers to disk and
reading them back again. It *looks* as if the pointers thus loaded
were reset before being used, but it's not particularly clear as the
main loop of this thing is goto-based FORTRAN translated lightly to C.
I've changed the logic to null these pointers instead of saving and
loading them, and things seem to still work.
The new save files have a header, support versioning, write only sized
types in network byte order, and for the toy encryption to discourage
cheating do something self-contained instead of using random(3) as a
stream cipher.
Because between the original import from 4.4 until earlier today
trying to save would result in SIGSEGV on most platforms, it's
unlikely anyone has a save file, but just in case (since the pointer
issue appears to be nonlethal) I've kept compat code for old save
files.
dholland [Sat, 7 Jan 2012 18:08:35 +0000 (18:08 +0000)]
Make this not crash on machines that are (a) 64 bit, or (b) have signed
chars by default (i.e., almost all machines). Makes it possible to save
the game. This has been broken since 4.4 and probably ever since the
FORTRAN -> C translation.
jakllsch [Tue, 6 Dec 2011 19:41:03 +0000 (19:41 +0000)]
Per [1] the speed of light in a vaccum is exactly 299792458 m/s.
Per [2] a furlong is 220 yards and a yard is exactly 0.9144 m.
Per [3] a fortnight is 14 days.
As I didn't find a good authority for what definition of a day a fortnight is
measured in, I'll assume here a day is 86400 SI seconds.
Thus, the speed of light in a vaccum is approximately
1.80*10^12 furlongs per fortnight.
[1] Resolution 1 of the 17th meeting of the CGPM (1983)
http://www.bipm.org/en/CGPM/db/17/1/
[2] Weights and Measures Act 1985
http://www.legislation.gov.uk/ukpga/1985/72
[3] The Concise Oxford Dictionary, 5th Edition, 1964, p. 480
dholland [Sat, 6 Aug 2011 20:18:26 +0000 (20:18 +0000)]
Use the right type for the malloc wrapper function, and don't cast the
return value.
(XXX: Except for a pile of allocation macros that produce typed pointer
results; there the typechecking of the result assignment is more valuable
than the warning if the alloc function isn't declared properly. These
macros should go away.)
is [Tue, 15 Feb 2011 08:25:25 +0000 (08:25 +0000)]
Bug fix: in a game with 26 planes, the last one to be allocated wouldn't
be allocated if it was the only eligible one.
From Jonathan David Amery via Debian Bug report 214626.
joerg [Sat, 15 May 2010 21:22:39 +0000 (21:22 +0000)]
Follow the Fundamental Theory of Algebra. Disallow factorising of
numbers less than 2 as it is not
- naturally unique (negative numbers)
- finite (0)
- non-empty (1)
-Fix an old bug in the "pollard" code: it gets its argument passed
by reference, and changes the value behind the pointer under some
circumstances (basically if it finds more than 2 different factors).
It also calls itself if it finds a factor which is not considered prime
(by openssl's miller-rabin check) and uses the call argument afterwards.
This doesn't work -- we need to copy the argument into its own storage.
-Modify the code to do the "rho" algorithm as was initially announced.
It takes somewhat longer in rare cases, but still works in cases where
the "p-1" algorithm is unusable. This might fix PR misc/43192
by Luiz Henrique de Figueiredo.
-Add some optional debug support, minor cleanup.
Handle the "diedtime" field of the player log (which is not the high
scores file, the append-only log of all games) as int32_t instead of
time_t. Log files from before the 64-bit time_t change can now be read
again; however, log files from the last year of -current are hosed.
All none of you who play larn, take note...
fix an obvious flaw in bounds check: the array of precomputed primes
could be overrun if its last entry (65537) was a factor of the input
(this does not affect PR misc/43192 -- the factors are much larger
here: 7742394596501*159455563099482401)