gh-libtom/libtomcrypt
Watch
1
0
Fork
You've already forked libtomcrypt
 0
Code Issues 42 Pull requests 17 Releases 9 Wiki Activity

RC5 - compiler warnings (Windows x64) #306

New issue
Closed
opened 2017-10-02 15:26:20 -05:00 by karel-m · 27 comments
karel-m commented 2017-10-02 15:26:20 -05:00 (Migrated from github.com)

Visual C/C++ 2008

1>.\src\math\ltm_desc.c(92) : warning C4244: 'function' : conversion from 'ltc_mp_digit' to 'unsigned long', possible loss of data
1>.\src\math\ltm_desc.c(135) : warning C4244: 'function' : conversion from 'ltc_mp_digit' to 'mp_digit', possible loss of data
1>.\src\math\ltm_desc.c(217) : warning C4244: 'function' : conversion from 'ltc_mp_digit' to 'mp_digit', possible loss of data
1>.\src\math\ltm_desc.c(233) : warning C4244: 'function' : conversion from 'ltc_mp_digit' to 'mp_digit', possible loss of data
1>.\src\math\ltm_desc.c(249) : warning C4244: 'function' : conversion from 'ltc_mp_digit' to 'mp_digit', possible loss of data
1>.\src\math\ltm_desc.c(284) : warning C4244: 'function' : conversion from 'ltc_mp_digit' to 'mp_digit', possible loss of data

related to:

mp_cmp_d
mp_add_d
mp_sub_d
mp_mul_d
mp_mod_d
mp_set_int

@sjaeckel do we want to fix them?

Visual C/C++ 2008 ``` 1>.\src\math\ltm_desc.c(92) : warning C4244: 'function' : conversion from 'ltc_mp_digit' to 'unsigned long', possible loss of data 1>.\src\math\ltm_desc.c(135) : warning C4244: 'function' : conversion from 'ltc_mp_digit' to 'mp_digit', possible loss of data 1>.\src\math\ltm_desc.c(217) : warning C4244: 'function' : conversion from 'ltc_mp_digit' to 'mp_digit', possible loss of data 1>.\src\math\ltm_desc.c(233) : warning C4244: 'function' : conversion from 'ltc_mp_digit' to 'mp_digit', possible loss of data 1>.\src\math\ltm_desc.c(249) : warning C4244: 'function' : conversion from 'ltc_mp_digit' to 'mp_digit', possible loss of data 1>.\src\math\ltm_desc.c(284) : warning C4244: 'function' : conversion from 'ltc_mp_digit' to 'mp_digit', possible loss of data ``` related to: ``` mp_cmp_d mp_add_d mp_sub_d mp_mul_d mp_mod_d mp_set_int ``` @sjaeckel do we want to fix them?
karel-m commented 2017-10-02 16:20:08 -05:00 (Migrated from github.com)

IMO the following stuff is not completely correct:

#ifdef ENDIAN_64BITWORD
typedef ulong64 ltc_mp_digit;
#else
typedef ulong32 ltc_mp_digit;
#endif

Because with MS C/C++ compiler for x86_64:

  • ltm's mp_digit is 32bit unsigned integer
  • ltc's ltc_mp_digit is 64bit unsigned integer
  • unsigned long is 32bit unsigned integer
IMO the following stuff is not completely correct: ```C #ifdef ENDIAN_64BITWORD typedef ulong64 ltc_mp_digit; #else typedef ulong32 ltc_mp_digit; #endif ``` Because with MS C/C++ compiler for x86_64: * ltm's `mp_digit` is 32bit unsigned integer * ltc's `ltc_mp_digit` is 64bit unsigned integer * `unsigned long` is 32bit unsigned integer
sjaeckel commented 2017-10-02 16:26:50 -05:00 (Migrated from github.com)

Yeah, I also think we should fix this.

Not 100% sure, but I guess that's the correct question to resolve this: Why is mp_digit 32bits with MS C/C++ compiler for x86_64?

Yeah, I also think we should fix this. Not 100% sure, but I guess that's the correct question to resolve this: Why is `mp_digit` 32bits with MS C/C++ compiler for x86_64?
karel-m commented 2017-10-02 17:05:02 -05:00 (Migrated from github.com)

Why is mp_digit 32bits with MS C/C++ compiler for x86_64?

Because ltm is not MSVC+64bit friendly. Even on 64bit Windows you have just:

MP_PROVIDER  = LibTomMath
MP_DIGIT_BIT = 28

Frankly, it is so bad that "stock" ltm does not even compile with Visual C/C++ 2008, I have to use my patched version (you perhaps remember my lost battle regarding stdint.h).

I am not sure what is the right fix here.

  • Unconditionally typedef ulong32 ltc_mp_digit;?
  • Or typedef unsigned long ltc_mp_digit;?
> Why is mp_digit 32bits with MS C/C++ compiler for x86_64? Because ltm is not MSVC+64bit friendly. Even on 64bit Windows you have just: ```C MP_PROVIDER = LibTomMath MP_DIGIT_BIT = 28 ``` Frankly, it is so bad that "stock" ltm does not even compile with Visual C/C++ 2008, I have to use my patched version (you perhaps remember my lost battle regarding `stdint.h`). I am not sure what is the right fix here. * Unconditionally `typedef ulong32 ltc_mp_digit;`? * Or `typedef unsigned long ltc_mp_digit;`?
sjaeckel commented 2017-10-02 17:45:52 -05:00 (Migrated from github.com)

...you perhaps remember my lost battle regarding stdint.h

I don't see where you've lost a battle there. I count it as a victory against cruft caused by crappy ancient toolchains

Unconditionally typedef ulong32 ltc_mp_digit;?

I think that's definitively the wrong approach

Or typedef unsigned long ltc_mp_digit;?

that's the way it was before which was less than optimal for the world where unsigned long on 64bit is only 32bit, but at least consistent across the platform the libs are built for...

I am not sure what is the right fix here.

I'd say either drop support for MSVC+64bit or fix the ltm build

In my opinion ltc_mp_digit is correctly typedef'ed, as I defined that the MPI provider's digit shall have the same bitwidth as the architeture so we can at least get out of the unsinged long hell.

btw I just tried to setup the windows toolchain (nmake etc.) in a vm to reproduce this mess and after spending more than an hour I feel like I've lost several days of my life...

where's the real problem of getting ltm built correctly for MSVC+64bit? could it be solved by something like packaging the mentioned pstdint.h and adding #if _MSC_VER #include "pstdint.h" #else #include <stdint.h> #endif? or does it need more?

Edit: FTR https://github.com/libtom/libtommath/issues/45

> ...you perhaps remember my lost battle regarding `stdint.h` I don't see where you've lost a battle there. I count it as a victory against cruft caused by ~~crappy~~ ancient toolchains > Unconditionally typedef ulong32 ltc_mp_digit;? I think that's definitively the wrong approach > Or typedef unsigned long ltc_mp_digit;? that's the way it was before which was less than optimal for the world where `unsigned long` on 64bit is only 32bit, but at least consistent across the platform the libs are built for... > I am not sure what is the right fix here. I'd say ~~either drop support for MSVC+64bit or~~ fix the ltm build In my opinion `ltc_mp_digit` is correctly typedef'ed, as I defined that the MPI provider's digit shall have the same bitwidth as the architeture so we can at least get out of the `unsinged long` hell. btw I just tried to setup the windows toolchain (nmake etc.) in a vm to reproduce this mess and after spending more than an hour I feel like I've lost several days of my life... where's the real problem of getting ltm built correctly for MSVC+64bit? could it be solved by something like packaging the mentioned `pstdint.h` and adding `#if _MSC_VER #include "pstdint.h" #else #include <stdint.h> #endif`? or does it need more? _Edit_: FTR https://github.com/libtom/libtommath/issues/45
karel-m commented 2017-10-02 18:17:46 -05:00 (Migrated from github.com)

... I defined that the MPI provider's digit shall have the same bitwidth as the architeture

IMO we build ltm on 64bit architectures like this:

  • if using a compiler that supports 128bit integers (needed for mp_word) then go DIGIT_BIT 60 way (which means 64bit mp_digit)
  • otherwise go DIGIT_BIT 28 way (which means 32bit mp_digit - even on 64bit arch)
  • so mp_digit's bitwidth does not strictly follow the architecture
> ... I defined that the MPI provider's digit shall have the same bitwidth as the architeture IMO we build ltm on 64bit architectures like this: * if using a compiler that supports 128bit integers (needed for `mp_word`) then go `DIGIT_BIT 60` way (which means 64bit `mp_digit`) * otherwise go `DIGIT_BIT 28` way (which means **32bit** `mp_digit` - even on **64bit** arch) * so mp_digit's bitwidth does not strictly follow the architecture
buggywhip commented 2017-10-02 18:41:20 -05:00 (Migrated from github.com)

On 2Oct, 2017, at 4:17 PM, karel-m notifications@github.com wrote:
... I defined that the MPI provider's digit shall have the same bitwidth as the architeture

IMO we build ltm on 64bit architectures like this:

if using a compiler that supports 128bit integers (needed for mp_word) then go DIGIT_BIT 60 way (which means 64bit mp_digit)
otherwise go DIGIT_BIT 28 way (which means 32bit mp_digit - even on 64bit arch)
so mp_digit's bitwidth does not strictly follow the architecture

Any way to confirm a match when init'ing a MP?

.

> On 2Oct, 2017, at 4:17 PM, karel-m <notifications@github.com> wrote: > ... I defined that the MPI provider's digit shall have the same bitwidth as the architeture > > IMO we build ltm on 64bit architectures like this: > > if using a compiler that supports 128bit integers (needed for mp_word) then go DIGIT_BIT 60 way (which means 64bit mp_digit) > otherwise go DIGIT_BIT 28 way (which means 32bit mp_digit - even on 64bit arch) > so mp_digit's bitwidth does not strictly follow the architecture Any way to confirm a match when init'ing a MP? .
karel-m commented 2017-10-02 19:05:53 -05:00 (Migrated from github.com)

BTW when talking about 128bit integers:

  • neither stdint.h nor pstdint.h is gonna save you
  • typedef unsigned __int128 mp_word; seems to not work with MSVC
  • typedef uint128_t mp_word; works only if you define your own uint128_t
  • thus some hacks in tomcrypt.h are inevitable
  • basically 128bit integers (DIGIT_BIT 60 way) work only with gcc
BTW when talking about 128bit integers: * neither `stdint.h` nor `pstdint.h` is gonna save you * `typedef unsigned __int128 mp_word;` seems to not work with MSVC * `typedef uint128_t mp_word;` works only if you define your own `uint128_t` * thus some hacks in `tomcrypt.h` are inevitable * basically 128bit integers (DIGIT_BIT 60 way) work only with gcc
karel-m commented 2017-10-02 19:16:41 -05:00 (Migrated from github.com)

Let's have look at GMP:

  • ltc's set_int(void *a, ltc_mp_digit b) calls mpz_set_ui(((__mpz_struct *)a), b)
  • GMP declares void mpz_set_ui (mpz_t rop, unsigned long int op)
  • on MS Windows/x64 unsigned long int op is 32bit

I am starting to like the old good unsigned long approach.

Let's have look at GMP: * ltc's `set_int(void *a, ltc_mp_digit b)` calls `mpz_set_ui(((__mpz_struct *)a), b)` * GMP declares `void mpz_set_ui (mpz_t rop, unsigned long int op)` * on MS Windows/x64 `unsigned long int op` is 32bit I am starting to like the old good `unsigned long` approach.
sjaeckel commented 2017-10-03 02:09:43 -05:00 (Migrated from github.com)

IMO we build ltm on 64bit architectures like this:

since 1.0.1 we build ltm on 64bit archtitectures like this v1.0.1/tommath.h:30:

  • if someone wants to use 8 or 16bit mp_int's do that
  • if it's a 64bit architecture use 128bit words and 64bit mp_int's
  • else use 64bit words and 32bit mp_int's

Any way to confirm a match when init'ing a MP?

no natural way

neither stdint.h nor pstdint.h is gonna save you

yeah, it's a mess

typedef unsigned __int128 mp_word; seems to not work with MSVC

looks like I dreamed of a better world when I added this... looks also like nobody uses ltm on 64bit windows...

I am starting to like the old good unsigned long approach.

me too

> IMO we build ltm on 64bit architectures like this: since 1.0.1 we build ltm on 64bit archtitectures like this [v1.0.1/tommath.h:30](https://github.com/libtom/libtommath/blob/v1.0.1/tommath.h#L30): * if someone wants to use 8 or 16bit mp_int's do that * if it's a 64bit architecture use 128bit words and 64bit mp_int's * else use 64bit words and 32bit mp_int's > Any way to confirm a match when init'ing a MP? no natural way > neither stdint.h nor pstdint.h is gonna save you yeah, it's a mess > typedef unsigned __int128 mp_word; seems to not work with MSVC looks like I dreamed of a better world when I added this... looks also like nobody uses ltm on 64bit windows... > I am starting to like the old good unsigned long approach. me too
buggywhip commented 2017-10-03 02:23:26 -05:00 (Migrated from github.com)

On 3Oct, 2017, at 12:09 AM, Steffen Jaeckel notifications@github.com wrote:
Any way to confirm a match when init'ing a MP?

no natural way

Perhaps a cautionary note in the PDF that all users should confirm the bit-architectures of their libraries match? Getting folks to pay attention to a single line in a 200-page manual is problematic so perhaps in the README? ???

.

> On 3Oct, 2017, at 12:09 AM, Steffen Jaeckel <notifications@github.com> wrote: > Any way to confirm a match when init'ing a MP? > > no natural way > Perhaps a cautionary note in the PDF that all users should confirm the bit-architectures of their libraries match? Getting folks to pay attention to a single line in a 200-page manual is problematic so perhaps in the README? ??? .
sjaeckel commented 2017-10-03 02:41:30 -05:00 (Migrated from github.com)

okay, let's summarize what we have and what we need to support (at least for the linux vs windows part. I guess we can squeeze the other *nix platforms in linux m32/64, or not @karel-m ?)

compiler os has 128bit unsigned long size
gcc linux m32 no* 4
gcc linux mx32 yes 4 (__x86_64__ + ILP32)
gcc linux m64 yes 8 (LP64)
cygwin-gcc win32 no** 4
cygwin-gcc win64 yes 8 (LP64)
mingw-gcc win32 no*** 4
mingw-gcc win64 yes 4 (LLP64)
msvc win32 no 4
msvc win64 no 4 (LLP64)
any Solaris/AIX/HPUX/32bit ? 4
any Solaris/AIX/HPUX/64bit ? 8 (LP64)

Tested typedef unsigned long my128type __attribute__ ((mode(TI)));

  • * gcc 4.4.7/i686-redhat-linux complains error: unable to emulate ‘TI’
  • ** gcc 5.4.0/i686-pc-cygwin complains error: unable to emulate ‘TI’
  • *** gcc 4.9.2/i686-w64-mingw32 complains error: unable to emulate 'TI'

I saw that there is _m128i on msvc, but I guess it can't be used for that purpose as it seems to be a struct from the msvc documentation...

+ I've created https://github.com/libtom/libtommath/pull/91

okay, let's summarize what we have and what we need to support (at least for the linux vs windows part. I guess we can squeeze the other *nix platforms in linux m32/64, or not @karel-m ?) compiler | os | has 128bit | unsigned long size ----------- | -- | -------- | ---------- gcc | linux m32 | no* | 4 gcc | linux mx32 | yes | 4 (`__x86_64__` + ILP32) gcc | linux m64 | yes | 8 (LP64) cygwin-gcc | win32 | no** | 4 cygwin-gcc | win64 | yes | 8 (LP64) mingw-gcc | win32 | no*** | 4 mingw-gcc | win64 | yes | 4 (LLP64) msvc | win32 | no | 4 msvc | win64 | no | 4 (LLP64) any | Solaris/AIX/HPUX/32bit | ? | 4 any | Solaris/AIX/HPUX/64bit | ? | 8 (LP64) Tested `typedef unsigned long my128type __attribute__ ((mode(TI)));` * `*` gcc 4.4.7/i686-redhat-linux complains `error: unable to emulate ‘TI’` * `**` gcc 5.4.0/i686-pc-cygwin complains `error: unable to emulate ‘TI’` * `***` gcc 4.9.2/i686-w64-mingw32 complains `error: unable to emulate 'TI'` I saw that there is _m128i on msvc, but I guess it can't be used for that purpose as it seems to be a struct from the msvc documentation... \+ I've created https://github.com/libtom/libtommath/pull/91
sjaeckel commented 2017-10-03 05:40:04 -05:00 (Migrated from github.com)

@karel-m thanks for filling in the values, linux mx32 has 128bit int's for sure as it's 64bit architecture but with 32bit wide pointers.

~/devel/open_source/libtommath $ CFLAGS="-mx32" make -j5 test_standalone
...
~/devel/open_source/libtommath $ ./test
Digit size 64 Bit 
Size of mp_digit: 8
Size of mp_word: 16
DIGIT_BIT: 60
MP_PREC: 32
...
~/devel/open_source/libtommath $ file test
test: ELF 32-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /libx32/ld-linux-x32.so.2, for GNU/Linux 3.4.0, BuildID[sha1]=73c8208e21219fc962d2728810643777679d483a, not stripped
@karel-m thanks for filling in the values, linux mx32 has 128bit int's for sure as it's 64bit architecture but with 32bit wide pointers. ``` ~/devel/open_source/libtommath $ CFLAGS="-mx32" make -j5 test_standalone ... ~/devel/open_source/libtommath $ ./test Digit size 64 Bit Size of mp_digit: 8 Size of mp_word: 16 DIGIT_BIT: 60 MP_PREC: 32 ... ~/devel/open_source/libtommath $ file test test: ELF 32-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /libx32/ld-linux-x32.so.2, for GNU/Linux 3.4.0, BuildID[sha1]=73c8208e21219fc962d2728810643777679d483a, not stripped ```
sjaeckel commented 2017-10-03 05:54:13 -05:00 (Migrated from github.com)

Could this be the correct patch?

diff --git a/src/headers/tomcrypt_cfg.h b/src/headers/tomcrypt_cfg.h
index 8c0866b..47acf1b 100644
--- a/src/headers/tomcrypt_cfg.h
+++ b/src/headers/tomcrypt_cfg.h
@@ -235,3 +235,3 @@ LTC_EXPORT int   LTC_CALL XSTRCMP(const char *s1, const char *s2);
 
-#ifdef ENDIAN_64BITWORD
+#if defined(ENDIAN_64BITWORD) && !defined(__LLP64__)
 typedef ulong64 ltc_mp_digit;

Edit: I just tested the three architectures (-m32 -mx32 -m64) on x86_64 with gcc 5.4.0 and they were all still fine

Could this be the correct patch? ``` diff --git a/src/headers/tomcrypt_cfg.h b/src/headers/tomcrypt_cfg.h index 8c0866b..47acf1b 100644 --- a/src/headers/tomcrypt_cfg.h +++ b/src/headers/tomcrypt_cfg.h @@ -235,3 +235,3 @@ LTC_EXPORT int LTC_CALL XSTRCMP(const char *s1, const char *s2); -#ifdef ENDIAN_64BITWORD +#if defined(ENDIAN_64BITWORD) && !defined(__LLP64__) typedef ulong64 ltc_mp_digit; ``` _Edit:_ I just tested the three architectures (-m32 -mx32 -m64) on x86_64 with gcc 5.4.0 and they were all still fine
karel-m commented 2017-10-03 09:31:15 -05:00 (Migrated from github.com)

There is IMO no guarantee that
LLP64 will be defined on
all LLP64 platforms.

I am for unconditional:
typedef unsigned long ltc_mp_digit;

There is IMO no guarantee that __LLP64__ will be defined on all LLP64 platforms. I am for unconditional: `typedef unsigned long ltc_mp_digit;`
rofl0r commented 2017-10-03 09:45:38 -05:00 (Migrated from github.com)

There is IMO no guarantee that
__LLP64__ will be defined on
all LLP64 platforms.

yes, there are certain properties of implementations that can not be detected at compile time with preprocessor hacks.... that's why most projects use configure scripts to test such properties (and that makes a ton of sense).

> There is IMO no guarantee that > `__LLP64__` will be defined on > all LLP64 platforms. yes, there are certain properties of implementations that can not be detected at compile time with preprocessor hacks.... that's why most projects use configure scripts to test such properties (and that makes a ton of sense).
sjaeckel commented 2017-10-03 09:48:06 -05:00 (Migrated from github.com)

I am for unconditional:

typedef unsigned long ltc_mp_digit;

this breaks x32 which was the reason why I introduced ltc_mp_digit (c.f. #51)

> I am for unconditional: > > typedef unsigned long ltc_mp_digit; this breaks `x32` which was the reason why I introduced `ltc_mp_digit` (c.f. #51)
sjaeckel commented 2017-10-03 10:00:28 -05:00 (Migrated from github.com)

better like that?

-#ifdef ENDIAN_64BITWORD
+#if defined(ENDIAN_64BITWORD) && !(defined(__LLP64__) || defined(_MSC_VER))

that's why most projects use configure scripts to test such properties (and that makes a ton of sense).

yeah, as soon as we're done with this release I'm open to accept PR's and maintainerships regarding the build-environment

better like that? ``` -#ifdef ENDIAN_64BITWORD +#if defined(ENDIAN_64BITWORD) && !(defined(__LLP64__) || defined(_MSC_VER)) ``` > that's why most projects use configure scripts to test such properties (and that makes a ton of sense). yeah, as soon as we're done with this release I'm open to accept PR's and maintainerships regarding the build-environment
karel-m commented 2017-10-03 10:11:30 -05:00 (Migrated from github.com) 
#if defined(__ILP32__) || defined(_ILP32)
typedef unsigned long long ltc_mp_digit;
#else
typedef unsigned long ltc_mp_digit;
#endif

UPDATE: also broken, does not cover mingw-gcc/win64

``` #if defined(__ILP32__) || defined(_ILP32) typedef unsigned long long ltc_mp_digit; #else typedef unsigned long ltc_mp_digit; #endif ``` UPDATE: also broken, does not cover mingw-gcc/win64
karel-m commented 2017-10-03 10:28:42 -05:00 (Migrated from github.com)

Anyhow, we should perhaps recommend not to pass integers bigger than 0xFFFFFFFF (32bit) to any of mp_cmp_d, mp_add_d, mp_sub_d, mp_mul_d, mp_mod_d, mp_set_int.

Anyhow, we should perhaps recommend not to pass integers bigger than `0xFFFFFFFF` (32bit) to any of `mp_cmp_d`, `mp_add_d`, `mp_sub_d`, `mp_mul_d`, `mp_mod_d`, `mp_set_int`.
sjaeckel commented 2017-10-03 10:31:57 -05:00 (Migrated from github.com) 
-#if defined(__ILP32__) || defined(_ILP32)
+#if defined(ENDIAN_64BITWORD) && (defined(__ILP32__) || defined(_ILP32))
``` -#if defined(__ILP32__) || defined(_ILP32) +#if defined(ENDIAN_64BITWORD) && (defined(__ILP32__) || defined(_ILP32)) ```
👍 1
sjaeckel commented 2017-10-03 12:20:47 -05:00 (Migrated from github.com)

UPDATE: also broken, does not cover mingw-gcc/win64

damn, right

> UPDATE: also broken, does not cover mingw-gcc/win64 damn, right
karel-m commented 2017-10-03 12:56:43 -05:00 (Migrated from github.com)

I would simply ignore it for now, it is not worse than it used to be.

To me the GMP approach (*_ui + unsigned long) seems the right way:

  • GMP: mp_add_d(void *a, unsigned long b, void *c) > mpz_add_ui(mpz_t rop, const mpz_t op1, unsigned long int op2)
  • LTC: mp_add_d(void *a, unsigned long b, void *c) > mp_add_ui(mp_int *a, unsigned long b, mp_int *c)
  • the hypothetical LTM function mp_add_ui knows how to convert unsigned long to mp_digit, as inside LTM it has all necessary information about how the LTM was built, DIGIT_BITS, how big mp_digit is etc.
  • all what we are trying here is to somehow guess/match from LTC how LTM was build and act accordingly; IMO LTC should not depend on any LTM internals (like the size of mp_digit)
I would simply ignore it for now, it is not worse than it used to be. To me the GMP approach (`*_ui` + `unsigned long`) seems the right way: * GMP: `mp_add_d(void *a, unsigned long b, void *c)` > `mpz_add_ui(mpz_t rop, const mpz_t op1, unsigned long int op2)` * LTC: `mp_add_d(void *a, unsigned long b, void *c)` > `mp_add_ui(mp_int *a, unsigned long b, mp_int *c)` * the hypothetical LTM function `mp_add_ui` knows how to convert `unsigned long` to `mp_digit`, as inside LTM it has all necessary information about how the LTM was built, DIGIT_BITS, how big `mp_digit` is etc. * all what we are trying here is to somehow guess/match from LTC how LTM was build and act accordingly; IMO LTC should not depend on any LTM internals (like the size of `mp_digit`)
sjaeckel commented 2017-10-03 13:07:47 -05:00 (Migrated from github.com)

I've pushed again to https://github.com/libtom/libtomcrypt/tree/fix/306 after accidentally pushing the incomplete commit to the release branch...

This was tested on 64bit cygwin, 64bit mingw, linux m32 mx32 & m64
Can you please try with MSVC

...Don't forget to use the correct branch of ltm..

I've pushed again to https://github.com/libtom/libtomcrypt/tree/fix/306 after accidentally pushing the incomplete commit to the release branch... This was tested on 64bit cygwin, 64bit mingw, linux m32 mx32 & m64 Can you please try with MSVC ...Don't forget to use the correct branch of ltm..
sjaeckel commented 2017-10-03 13:14:51 -05:00 (Migrated from github.com)

To me the GMP approach (*_ui + unsigned long) seems the right way:

IMO there are two good types for b of mp_add_d()

  1. unsigned int
  2. unsigned long long

Edit: or probably also not... IDK... probably it should also be uint32_t or uint64_t and we don't have to care anymore about data models... yada yada

> To me the GMP approach (*_ui + unsigned long) seems the right way: IMO there are two good types for `b` of `mp_add_d()` 1. `unsigned int` 2. `unsigned long long` _Edit:_ or probably also not... IDK... probably it should also be `uint32_t` or `uint64_t` and we don't have to care anymore about data models... yada yada
karel-m commented 2017-10-03 14:10:04 -05:00 (Migrated from github.com)

fix/306 seems to build fine with MSVC

`fix/306` seems to build fine with MSVC
karel-m commented 2017-10-08 02:36:05 -05:00 (Migrated from github.com)

@sjaeckel fix/306 can be merged, or did you already?

@sjaeckel fix/306 can be merged, or did you already?
sjaeckel commented 2017-10-08 08:34:13 -05:00 (Migrated from github.com)

@sjaeckel fix/306 can be merged, or did you already?

already merged and branch removed

> @sjaeckel fix/306 can be merged, or did you already? already merged and branch removed
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
develop
archive/20260923T145428Z-rescue/illiliti/static
archive/20260923T145428Z-rescue/afonsojanu/fix/pss-decode-siglen-check
archive/20260923T145428Z-rescue/joshbuddy/win64
pr/pqc1
archive/20260923T151904Z-recovered/pr/pqc1
archive/20260923T151904Z-recovered-3/pr/pqc1
archive/20260923T151904Z-recovered-2/pr/pqc1
archive/20260923T145428Z-rescue/MarekKnapek/serpent-accelerated
pr/sm2
pr/xsalsa20-hsalsa20
no-struct-padding
archive/20260923T145428Z-rescue/tags/actions/runs/24841441691
archive/20260923T145428Z-rescue/tags/actions/runs/24821326727
archive/20260923T145428Z-rescue/tags/actions/runs/24769074231
archive/20260923T145428Z-rescue/tags/actions/runs/24762001029
archive/20260923T145428Z-rescue/tags/actions/runs/24646701081
archive/20260923T145428Z-rescue/tags/actions/runs/24646842340
archive/20260923T145428Z-rescue/tags/actions/runs/24595690628
archive/20260923T145428Z-rescue/tags/actions/runs/24590716227
archive/20260923T145428Z-rescue/tags/actions/runs/24590979385
x509_import
appveyor/sha-ni
ci/develop
debug-wycheproof-failures
turboshake
appveyor/aesni
ci/x509_import
wip/pr/477
remove-prng-registry
pr/macro-LTC_NO_WIN32_BCRYPT
fix-perl-cryptx-99
appveyor/msvc2012
fix-alignment
archive/20260923T145428Z-rescue/assarbad/premake4-vs-project-generation
fix-622
regression-test-for-546
archive/20260923T145428Z-rescue/cntrump/pr_swiftpm_support
timing-benchmark
fix-b64-zero-length-array
openssh-privkey
archive/20260923T145428Z-rescue/FredeJ/visualstudio_solution
travis-test
streams-functions_in_separate_files
streams-enforce-call-policy
pr/autotools
master
feature/gcm_file
feature/eccAddA
v1.18.2
v1.18.1
v1.18.0
v1.18.0-rc5
v1.18.0-rc4
v1.18.0-rc3
v1.18.0-rc2
v1.18.0-rc1
1.17
1.16
1.15
1.14
1.13
1.12
1.11
1.10
1.09
1.08
1.07
1.06
1.05
1.04
1.03
1.02
1.01
1.00
0.99
0.98
0.97b
0.97a
0.97
0.96
0.95
0.94
0.93
0.92
0.91
0.90
0.89
0.88
0.87
0.86
0.85
0.84
0.83
0.82
0.81
0.80
0.79
0.78
0.77
0.76
0.75
Labels
Clear labels   
bug

   
duplicate

   
enhancement

   
feature

   
help wanted

   
improve API

   
invalid

   
needs documentation

   
not-planned
This ticket is not planned to be implemented and/or fixed from the core team.

  
rtfm

   
stale

   
support

   
wishlist
No labels
bug
duplicate
enhancement
feature
help wanted
improve API
invalid
needs documentation
not-planned
rtfm
stale
support
wishlist
Milestone
Clear milestone
No items
No milestone
v1.18.0
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
gh-libtom/libtomcrypt#306
No description provided.