Hello

I'm trying to create a Debian package for Perl6. This packaging is currently blocked by a test failure. The root cause of this failure is fixed in libtommath by commit 6907f6ca4582064f28e3a58374083ab2a4d85418 (merged).

To provide a proper Perl6 package, this library must be provided by libtommath Debian package which is at version 0.42.0 (4 years old).

I'd like to create a new version of libtommath package so that the above fix is available for Debian users (and Perl6 package).

To make this work much easier, could you create a new release of libtommath ?

All the best

It is a bit slower (although completely unoptimized yet) but independent of anything but float.h and the macros DBL_EXP_MAX and FLT_RADIX therein. The same code can be used for floatwith minimal changes (just change DBL_EXP_MAX to FLT_EXP_MAX ). The same could be said for long double but that needs some more tests because of the slightly different format of long double and not everyone has it.

It is now independent from the type of the architecture and its memory-layout. The values of DBL_EXP_MAXandFLT_RADIXcould be hardcoded to avoid the inclusion offloat.hbut the existence offloat.h` is a good sign for the existence for the availability of at least some floating point functions.

Just brought the implementation up to state-of-the-art, nothing else changed. Halfs the cut-off point and brings it therefore into the expected region. The expected region is a bit less than twice the Karatsuba cut-off point and that is where it is now.

This code was part of #227.

Hello

Moarvm (Rakudo/Perl6 VM) is using libtommath from April 2018 (https://github.com/MoarVM/libtommath/tree/289e346bb9b968377ffbbbe6876342fedda4e072).

As Debian packager, I'm building MoarVM with the last version of libtommath (1.0.1) which was released in August 2017.

I've currently have not seen a problem using Rakudo with this old version of libtommath. But, the increasing gap of libtommath version between Rakudo development and Debian build is making me nervous.

Since libtommath was last released a year ago and the development is quite active (119 commits since 1.0.1), it may be time to cut a new release...

Thoughts ?

@sjaeckel Would it make sense to cut a new release at some point and remove deprecated stuff afterwards? Are there open issues right now which stand in the way of a new release?

Or do you want to have all the open PRs resolved until then?

This series contains:

• the PR #40 (6 patches)
• the end of linting (3 patches)
• preparation for using a code formatter

Now, I am ready to use the code formatter astyle (with https://gist.github.com/fperrad/c9a7f6c457962ee6dba9). But I don't know which is the correct indentation: 2, 3 or 4 spaces.

Also changed mp_radix_size to use mp_ilogb while deprecating it at the same time and rewrote mp_fwrite to use mp_radix_sizeinbase instead.

See comment in bn_mp_fwrite.c for some of the consequences.

See #214. I wanted to try again if I can make this work without using variadic macros, this time only relying on C89.

@karel-m Could you please try again your compiler suite?

@sjaeckel @czurnieden This PR is simpler and better than the one before. Hopefully it also works on older compilers. This helps to clean up control flow. Another advantage is that the compiler will check all branches. Dead code elimination will make sure that the dead branches are not compiled.

When importing the "develop" branch of libtom/libtommath into Tcl, it broke the win32 build. The reason is that no header file is used which defines uint8_t, still this symbol is used in tommath_private.h and bn_mp_radix_smap.c. (the use in tommath.h is harmless, since Tcl doesn't use MP_8BIT)

See #164. These are only internal functions, no API or ABI changes. The renaming is done by the script. If something needs tweaking only the script should be changed and executed again.

• Activate on the develop branch
• Activate on branches containing the word v-algrind (without hyphen)
• Activate if the commit message contains v-algrind (without hyphen)

With valgrind the tests take about 15 minutes, without valgrind about 1 minute. We should not do that. I think it is bad for us and it is kind of abusive towards travis.

Ubuntu 18.04 has entered the deprecation phase and with it, a lot of the compilers we use to test will go (and new ones will be available).

Currently we test against:

clang: 4.0, 5.0, 6.0, 7, 8, 9, 10
gcc: 4.8, 5, 7, 8

Ubuntu 20.04 provides:

clang: 6.0, 7, 8, 9, 10, 11, 12
gcc: 7, 8, 9, 10

Ubuntu 22.04 provides:

clang: 11, 12, 13, 14
gcc: 9, 10, 11, 12

I.e. we will loose clang: 4.0, 5.0 and gcc: 4.8, 5 soon and in two years then we'll loose clang: 6.0, 7, 8, 9, 10 and gcc: 7, 8

Does someone need those compiler versions to be tested?

This adds an option to use a heap-buffer for the usually stack-based MP_WARRAY-sized temporary buffers.

Per default it will reserve a single buffer, which can be modified

• at compile-time via the MP_WARRAY_NUM define
• at run-time by calling mp_warray_init()

The internal structure can only be created once. If one wants to modify the maximum number of elements, the entire structure has to be free'd by calling mp_warray_free().

In case one wants to use this option with multiple threads, one shall use the mp_warray_init() function and pass appropriate locking functions.

Timings

| op / algo | ECC | RSA | | ------------ | ------ | ------ | | decrypt_key | | | | encrypt_key | | | | sign_hash | | | | verify_hash | | |

Related to: #441 #447 #511

Creating this issue in order to pull the discussion regarding a mp_isone() macro out of #532

Following up on https://github.com/libtom/libtommath/pull/532#issuecomment-1265290821

[...] It might be tempting to generalize it but since the size of a mp_digit is not fixed over different architectures it would get too complex.

I just thought about it a bit more and had a look into mp_cmp_d() and only then realized that #define mp_isone(a) ( ((a)->used == 1u) && ((a)->dp[0] == 1u) ) would falsely claim -1 as one ...

So I have some follow up questions:

1. maybe it'd be a better idea to have an inline version of mp_cmp_d()?
   • does the function-call overhead really matter that much? I can imagine that it matters, but have no clue to what extent. Did someone measure this?
   • are there any other candidates that could/should be inlined?
   • how will we do that? We're still providing C89 support, so I guess we can't expect all those compilers being able to handle inline functions correctly.
2. maybe it's time to think about starting to merge in tfm?
   • Which functions should we start with?
   • Which architectures?

Set a closer initial value for iteration and remove some unnecessary code. By the way, in the first for loop, one of the err=MP_OKAY branches (never reached) did not set c.

Arguably it could be tested on other old compilers (ancient Watcom comes to mind) and the switching could be done based on checking against the standard version, e.g.:

#if (__STDC_VERSION__ < 199901L)
#include <tommath_c89.h> /* an extended version of the current one */
#else
#include <stdint.h>
#include <stdbool.h>
#endif

(or invert the condition order, I don't care)

Either way this would improve the robustness and have all compilers benefit from the C89 compatibility, not just builds done with that makefile where some sed command creates an illusion of compatibility by changing the source files prior to a build (something that in my book is a big no no when building third-party code).

I would also recommend renaming the makefile to GNUmakefile and then consolidating its contents. E.g. for the assignment to OBJECTS it could use something akin to what the pre_gen (amalgamation) target has:

SOURCES:=$(wildcard *mp_*.c)
OBJECTS:=$(SOURCES:.c=.o)

Rationale: if you already have a special makefile for GNU make it makes sense to make this explicit and limit its scope to GNU make. A makefile by the name GNUmakefile will be picked up first by GNU make (it has several names hardcoded), even before makefile. So it could in fact work to rename the current makefile to GNUmakefile then rename the current makefile.unix to makefile. The behavior should be the same, except that on BSD you no longer need to specify the file name.

For the most part when using GNU make I'd also recommend immediate assignments (:=) as opposed to lazy ones (=).