View Single Post
Old 2021-09-01, 22:18   #2
ewmayer's Avatar
Sep 2002
Rep├║blica de California

22·37·79 Posts

Brief post illustrating how users who hit the v20 assignment-borkage-due-to-missing-string-terminator issue mentioned in the above list can manually patch up affected assignments, which is preferable to the code skipping them due to "unable to parse" reasons. Here the original example sent to me by tdulcet:
cat worktodo.ini
Test=F3AC27E83049B4409813291299C836B3,113334787,76,1", "fft-length":5767168, "B1":900000, "factors":[188971360622975631014921], "program":{"name":"Mlucas", "version":"20.0"}, "timestamp":"2021-08-27 13:58:46 GMT", "aid":"74ECE80F64762AFE11E83B9818CF3A46"}
The program has split a Test= assignment ending in ",76,0", with the trailing 0 indicating "no p-1 has been done", into a p-1 assignment and the same Test= assignment, but then it tries to replace the railing 0 with a 1, so if the p-1 does not find a factor, things proceed to the LL-test, but that is now flagged as "p-1 has been done" so does not again get split into A P-1/Test pair. The problem is that my initial implementation of this failed to first insert a string-terminating null '\0' following the "...,76,". The same string buffer had in the meantime also been used to hold a JSON-output line for writing to results.txt, so the ensuing strcat() with "1\n" left all the JSON-line contents following the "76," and appended the "1\n" starting with the string-terminator for the JSON output, which ends with ...A46"}.

Long story short, if you end up with such a mangled Test= (or DoubleCheck=) assignment in your worktodo.ini file, delete everything following the "[TF bits]," and replace with a "1"; in the above example the fixed-up assignment would be
(Note that the 1 following the ,76 in the mangled assignment was a coincidence, it was the rightmost digit of the found factor reported in the JSON output, 188971360622975631014921.)

For PRP assignments mangled similarly, note that the trailing-digit convention is different than for Test/DoubleCheck: for PRP assignments, the trailing digit represents "PRP tests saved if a p-1 factor is found", thus a p-1/PRP assignment pair mangled like this:
PRP=C57FF1C644A0CB16F5E2B5B3A9FC4E1D,1,2,98024161,-1,77,[stuff leftover from previous write of char-buffer]0
gets demangled like so:
with the trailing ",0" in the PRP= assignment being PRP version of "p-1 has been done".

Apologies for the fubar - all my tests of the assignment-splitting code happened to be under debugger, which nulls everything including char-buffers from one run to the next. (I.e. the debugger was providing the needed string-terminating null.)
ewmayer is online now   Reply With Quote