Use stdint.h types more

[magv]

Hi, all. Another minor cleanup I want to propose is to use stdint.h types more.

The first step is the following. Currently there's some logic in configure.ac and form3.h to define INT16, INT32, INT64, and INT128. I think this logic can be safely dropped, and we can use int16_t, int32_t, int64_t types from stdint.h instead. INT128 is unused and can be dropped completely. Things like STATIC_ASSERT(sizeof(INT64) == 8) can be dropped in the same sweep.

As before, if you'll agree, I'll work on the patches.

[jodavies]

This kind of type cleanup would probably be the right time to simultaneously remove 32-bit build-related logic from the code completely.

[magv]

Are you dropping 16-bit WORD support too? This would simplify things further. Or are you also dropping all 32-bit platforms altogether?

[jodavies]

The idea was that 32-bit builds would have deprecated status in FORM 5, but still be possible to compile (though in that case, flint and the floating point modes are anyway disabled...). Various tests in the suite are also disabled in 32-bit mode since they need too large a maxtermsize or simply consume too much memory.

I would not be against completely removing 32-bit support from the v5 release, but let's see what @tueda and @vermaseren think.

[magv]

We could set WORD to be 32-bit on all platforms (it is 16 bit at the moment, if I read form3.h correctly). This will not break the build on 32-bit platforms, they will still work, if someone will want to use them.

[jodavies]

My understanding is that WORD is half the machine width so that overflows are still handled with native integer types, before switching to GMP. So if you make WORDs 32bit on a 32bit system you will be using whatever the compiler gives you for 64bit emulation rather than GMP (but probably this also performs just fine...).

Of course you also make all of the coefficients twice the size on 32-bit systems, using a bit more of their already-constrained buffer sizes.

[vermaseren]

The question about the 32-bits version is: “On what computers is this still a necessity?”. Such computers must be rather old by now, and as long as version 4.3 is still supporting the 32-bits, there should not be a problem. People who developed programs under 32 bits can still run those. It is just that they cannot use the newer features and won’t get further updates. It can be compared to the transition from version 2 to version 3. Some people kept using version 2, but that was without further support. The only reason I can think of, to keep some 32-bits stuff in, is for being able to read .sav files, but I am not convinced that that is a sufficient reason for keeping the 32-bits. I interpreted the idea to keep it as deprecated as something that would cost us no extra work for the moment, and hence being nice to older users. I guess that the amount of work involved should be the dominant argument. No work: keep it in for now. Much work (also to maintain): toss it out.

…

On 19 Jun 2025, at 11:55, jodavies ***@***.***> wrote: The idea was that 32-bit builds would have deprecated status in FORM 5, but still be possible to compile (though in that case, flint and the floating point modes are anyway disabled...). Various tests in the suite are also disabled in 32-bit mode since they need too large a maxtermsize or simply consume too much memory. I would not be against completely removing 32-bit support from the v5 release, but let's see what @tueda <https://github.com/tueda> and @vermaseren <https://github.com/vermaseren> think. — Reply to this email directly, view it on GitHub <#670 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJPCEV3B6X5M4TLK6TVWQD3EKCH7AVCNFSM6AAAAAB7VMZTDWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGNJRHA3DAOA>. You are receiving this because you were mentioned.

[vermaseren]

Making WORD 32 bits on 32-bits computers will get you into a wasps nest. I can almost guarantee that you will generate lots of errors.

…

On 19 Jun 2025, at 12:00, Vitaly Magerya ***@***.***> wrote: We could set WORD to be 32-bit on all platforms (it is 16 bit at the moment, if I read form3.h correctly). This will not break the build on 32-bit platforms, they will still work, if someone will want to use them. — Reply to this email directly, view it on GitHub <#670 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJPCETMZXE454TUIJBEMZ33EKC45AVCNFSM6AAAAAB7VMZTDWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGNJRHA3DMMA>. You are receiving this because you were mentioned.

[tueda]

It may be OK to completely remove 32-bit support.

Note that we haven't released any version where 32-bit support is deprecated.

[jodavies]

Also on this topic: declare.h (and the associated functions) contains many functions which return int rather than WORD. Perhaps these should all be unified as WORD?

[magv]

Perhaps the other way round? Everything that returns error codes (0,1,-1) should be simply int, so that WORD would be reserved for numbers that live in buffers.

[vermaseren]

In the days of 32-bits, int and WORD were usually (but not always) different. The int meant that it should involve as little effort as possible. On the current 64-bits computers/compilers WORD and int are usually identical. But will that also be in the future? Probably yes, but it will be a lot of work to change all those declarations.

…

On 19 Jun 2025, at 13:42, jodavies ***@***.***> wrote: Also on this topic: declare.h (and the associated functions) contains many functions which return int rather than WORD. Perhaps these should all be unified as WORD? — Reply to this email directly, view it on GitHub <#670 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJPCEWXR2XTYHTALXNBNKT3EKO2TAVCNFSM6AAAAAB7VMZTDWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGNJRHE2DENA>. You are receiving this because you were mentioned.

[vermaseren]

That would indeed be better. But it will be a lot of work to make it all consistent.

…

On 19 Jun 2025, at 13:49, Vitaly Magerya ***@***.***> wrote: Perhaps the other way round? Everything that returns error codes (0,1,-1) should be simply int, so that WORD would be reserved for numbers that live in buffers. — Reply to this email directly, view it on GitHub <#670 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJPCERRW7CWXV2WIBXXCV33EKPVPAVCNFSM6AAAAAB7VMZTDWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGNJRHE2DSNY>. You are receiving this because you were mentioned.

[magv]

If there's consensus, I'll work on it.

[vermaseren]

Fine with me. It is just that you will have to look at each function individually, and that is a lot of work. And testing of course.

…

On 19 Jun 2025, at 13:59, Vitaly Magerya ***@***.***> wrote: If there's consensus, I'll work on it. — Reply to this email directly, view it on GitHub <#670 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJPCEXI44ACPQJNCIKM5GD3EKQYNAVCNFSM6AAAAAB7VMZTDWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGNJRHE2TQMQ>. You are receiving this because you were mentioned.

[magv]

The current proposed set of changes is in #674.