move to c99

[minad]

My proposal would be to move to c99 in 2.0. Unfortunately this means dropping support for legacy compilers. Some legacy compilers can still be used though if the source is compiled as C++ (I am looking at you, old MS compilers).

I would also propose to continue maintainance of the 1.* series with full legacy support and full backward compatibility. The maintainance would mainly include bugfixes and maybe additional features if someone is interested in doing the work.

The advantages are obvious:

• Better scoping
• Inline functions instead of macros
• stdint/stdbool available
• as of now we only test some more recent compilers in CI. Dropping support for older compilers will ease development. We simply cannot ensure that older compilers will continue to function if we cannot run tests with them.

Ping @sjaeckel, @czurnieden, @nijtmans

[minad]

I looked around and it seems many of the reverse dependencies are in fact c89 still. They will probably be forever. What many projects do however is to use selected features out of c99 as we already do (stdint.h).

For example as an unrelated, but exemplary project, python (see https://www.python.org/dev/peps/pep-0007/):

• stdint, bool
• mixed declarations and code
• C++ comments
• Inline functions

I am also not 100% happy with such a partial approach since it is not very well defined.

The risk that I am seeing if we are doing the full c99 move is a potential split of the library. Nobody will use ltm 2.0 and the 1.x users are not getting the improvements. B
This risk already exists since we are breaking compatibility. Doing it on the code level however is more problematic.

So the conservative choice would be to stay with c89 and only use light headers like stdint/stdbool from c99 since they also work on a c89 compiler.

I also wonder what the policy of ltc is, @sjaeckel?

[minad]

I think given the odds, I would stay conservatively here. For an application the choice might be different than for a library which is also often embedded in other codebases.

But having stdbool would still be good due to the static analysis issues.

[minad]

I added a helper command which performs the necessary c89 substitutions. This should also make the no-stdint-h branch obsolete. See #405. Besides that I don't want to go beyond c89.

[nijtmans]

FYI: I experimented in Tcl how to add replacement and files to the Tcl distribution, such that everything still compiles on Visual Studio 2008+. The result is here : Less hacks to be done in libtommath. Tcl already has a "compat" directory which can be used to supply replacement header files for systems lacking those.

This Tcl branch is not meant to be ever merged to master (since we only use stable libtommath releases), but at least it gives an idea which direction we are heading to.

There are still a few minor changes needed in libtommath, I will provide those in separte PR's

[minad]

Ok. I saw you added something like MP_INT_DECLARED. I don't think we will accept any changes here which make the mp_int struct opaque. This is not how the library has been made from the beginning. But I am happy that the solution with compat headers works for you. This is what I had in mind.

[minad]

@nijtmans btw - if you are vendoring only a subset of ltm, I can provide you with a script which produces a nice self contained amalgamation of only the used functions. All the functions are made static. Then you can include this amalgamation into the c file in tcl which performs the bigint ops. But in this case the ltm functions are only available in this single file. I don't know how spread things are over the tcl codebase.

[sjaeckel]

I can provide you with a script which produces a nice self contained amalgamation of only the used functions

that sounds neat! how about adding the script to ltm itself?

[minad]

This is similar to what @czurnieden made in #301, but @czurnieden seriously overengineered it there. My script is specific for my use case, but it should be no problem to generalize and upstream it here.

It basically does what gen.pl did before but only selected functions and all made static. Then this amalgamation can be included in the c file which uses it. This is useful if the math library is fully wrapped from the rest of the code.

[nijtmans]

Ok. I saw you added something like MP_INT_DECLARED. I don't think we will accept any changes here which make the mp_int struct opaque. This is not how the library has been made from the beginning.

The MP_INT_DECLARED is not meant to make mp_int opaque, it is meant to allow the use of mp_int in Tcl without depending on the header inclusion order. I don't expect you to have deep understanding how Tcl and libtommath cooperate, I can bring in that information if you want. If you don't want, that's OK too therefore Tcl still uses a libtommath fork ;-)

[minad]

I understood why you introduced it. If the struct is not defined by including tommath.h, the struct is opaque outside.

[minad]

@nijtmans But for sure I would like to hear what issues exactly you are working around in tcl. Then we can probably find a solution which will either require no patching or only minimal patching from your side. My point basically boils down to this - if we upstream workarounds from the tcl embedding to ltm, which are of no use outside tcl, they are probably not good patches. Otherwise I think patches/solutions are welcome. For example what I did with the c89 header. Even if you might not use it in the future, since you use compat headers. Even better then. As I said my goal is not to make it harder, but easier to embed ltm. But this should not come at the cost of introducing hacks here.