Thread: Mlucas v20.1 available View Single Post
 2021-09-01, 22:18 #2 ewmayer ∂2ω=0     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: Code: cat worktodo.ini Pminus1=F3AC27E83049B4409813291299C836B3,1,2,113334787,-1,900000,32000000 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"} 1 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 Code: Pminus1=F3AC27E83049B4409813291299C836B3,1,2,113334787,-1,900000,32000000 Test=F3AC27E83049B4409813291299C836B3,113334787,76,1 (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: Code: Pminus1=C57FF1C644A0CB16F5E2B5B3A9FC4E1D,1,2,98024161,-1,800000,29000000 PRP=C57FF1C644A0CB16F5E2B5B3A9FC4E1D,1,2,98024161,-1,77,[stuff leftover from previous write of char-buffer]0 gets demangled like so: Code: Pminus1=C57FF1C644A0CB16F5E2B5B3A9FC4E1D,1,2,98024161,-1,800000,29000000 PRP=C57FF1C644A0CB16F5E2B5B3A9FC4E1D,1,2,98024161,-1,77,0 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.)