Bugfixes to fp_prime_random_ex [reboot] #39
Conversation
|
Differences from #4:
|
|
TBH I'm not sure what we should do with stuff like that! We have advanced a lot more in LTM, especially with the work done by @minad and @czurnieden and all the others I forgot. The original plan was to merge LTM and TFM into one library, but that never took place because reasons. I think this API is a good example, the LTM counterpart is mp_prime_rand.c. Here we call The effort of @czurnieden that went into the prime checking and the complexity this now has, I don't think we should even think of porting this over to TFM. But then we're talking about a critical part FMU and what is done in TFM is just not OK. But maybe this discussion also belongs somewhere else and we should simply merge this stuff as is... |
|
I haven't been along for those discussions, and frankly didn't look at all at LTM to compare. I only looked at these changes, and they make sense to me. |
This is the only instance of dynamic memory in TFM. It can be avoided by writing directly into the dp[] array, and it does not violate C aliasing rules which specifically allow access on objects through char*. It does not matter the platform-specific representation of digits since we are filling them with random data anyway.
There are potential issues with weird platforms were not all bits of a fp_digit are used (padding bits), plus it makes it harder to do reproducible testing of algorithms.
sjaeckel
force-pushed
the
bugfix_gen_prime
branch
from
a1ad906
to
060d65d
Compare
This branch contains some fixes to
fp_prime_random_ex. See the specific commits. Specifically:This is a reboot of #4
This fixes #32