It would be great to implement the equivalent of mpz_powm and mpz_pow_ui of GMP.

Currently, the HEADERS list is generated by running ls *.h in the configure script. The problem is that the *_arch.h headers are not generated until later in the configure script, so these headers will not be listed. Also, the headers located in arch/inline are not listed.

Put #ifdef around the inclusion of malloc.h on (Free)BSD.

In the line r += b; in zz_divremi (zz.c:475), r and b can have large values that cause signed overflow.

For example, I believe running the t-zz test triggers a call where r == -4156049824137537374 and b == -7351016435385864854. (As noticed by ubsan, as I was trying to test unrelated functions I was adding.)

This is definitely a theoretical issue because signed overflow is undefined behavior in C, but have not attempted to determine if it's actually an issue that causes zz_divremi to have wrong values. (And, if there are no wrong values, an appropriate fix is just to cast things around for that addition.)

In the implementation of zz_get_str, it goes through the process of copying the input to a temporary (t) before using nn_get_str to do most of the work.

Is there any reason to make that copy?

As far as I can tell, it is unnecessary, since the input is read-only, and can just be used directly.

But, I am just starting to get familiar with this library, so not sure if I'm missing something...

I'm researching arb. precision libraries, and it wasn't immediately clear for bsdnt: is a given bignum's data always stored contiguously?
Some other bignum libs use some linked list data structure if the number gets big enough, but I didn't see any code like that here, so far — though perhaps I missed it.

Hi, nice project alternative to GNU MP

Is there any documentation on the functions as HTML or a help web page?

Or just read the source file comments?

One reason I am using GNU MP, or MPFR, or others, is they are documented and I can search google for help on them... But I love BSD licenses over gnu gpl.

Sorry, this is not much of an "issue" or bug report, but rather a discussion of documentation missing for the project.

There is this, though:
http://wbhart.blogspot.ca/2010/09/bsdnt-introduction.html

Is this the official documentation pages that are available so far?

The tests cause 1-word over-reads in nn_divapprox_classical_preinv_c.

The following patch makes this condition visible:

diff --git a/nn_quadratic.c b/nn_quadratic.c
index 9a71d5e..2a5c63c 100644
--- a/nn_quadratic.c
+++ b/nn_quadratic.c
@@ -312,6 +312,9 @@ word_t nn_divapprox_classical_preinv_c(nn_t q, nn_t a, len_t m, nn_src_t d,
    word_t cy = 0, d1 = d[n - 1];
    len_t s = m - n + 1;

+   nn_t orig_a = a;
+   nn_src_t orig_d = d;
+
    ASSERT(q != a);
    ASSERT(q != d);
    ASSERT(a != d);
@@ -352,7 +355,16 @@ word_t nn_divapprox_classical_preinv_c(nn_t q, nn_t a, len_t m, nn_src_t d,
       a--;
       /* rare case where truncation ruins normalisation */
       if (ci > d[s] || (ci == d[s] && nn_cmp_m(a - s + 1, d, s) >= 0))
+      {
+         // word_t xxx = (a-s)+1 + s+1  -  (orig_a + m);
+         // if(xxx > 0 && xxx < 9999)
+         //   printf(">>>%zx\n", xxx); // xxx should never be positive... but is sometimes 1.
+
+         // These asserts are the conditions for the nn_sub_m in _nn_divapprox_helper *not* accessing OOB
+         ASSERT(orig_a <= (a-s)+1 && (a-s)+1 + s+1 <= orig_a + m); // The second clause here is violated.
+         ASSERT(orig_d <= d && d + s+1 <= orig_d + n);
          return _nn_divapprox_helper(q, a - s, d, s);
+      }

       divapprox21_preinv2(q[s - 1], ci, a[0], dinv);

(Not sure what the fix is; reading math code is hard.)

Find a better way to handle:

nn_subquadratic.c: In function 'nn_mul_toom33':
nn_subquadratic.c:163: warning: value computed is not used

etc.

Use the more standard

!/usr/bin/env bash

in configure.

I am currently in the process of porting bsdnt to run on Windows, for my local project.

Are you interested in changes like that being merged back into the mainline?

I notice that in older releases, MSVC was supported, but it was removed in fb3037b.

Is it an anti-feature for this project?

I realize that the autoconf/bash-driven configuration for the arch/inline/xxx code is not easy to convert. I'm not planning on dealing with that, just updating the main plain-C codebase to compile under MSVC.

$ ./configure
BSDNT Unix Build Script.
BSDNT is a BSD-Licensed BigNum Library.

BSDNT is Copyright (C) its contributors. See LICENSE.

Examining source
Creating Makefile
expr: syntax error
sed: 1: "Makefile": invalid command code M
sed: 1: "Makefile": invalid command code M
sed: 1: "Makefile": invalid command code M
sed: 1: "Makefile": invalid command code M
sed: 1: "Makefile": invalid command code M
sed: 1: "Makefile": invalid command code M
sed: 1: "Makefile": invalid command code M
sed: 1: "Makefile": invalid command code M
sed: 1: "Makefile": invalid command code M
sed: 1: "Makefile": invalid command code M
sed: 1: "Makefile": invalid command code M
Done.

Type make to build this library. We strongly recommend you run
make check and ensure all tests pass.

$ make check
Makefile:96: *** missing separator. Stop.

Suppress the following:

arch/inline/nn_linear_x86_64_core2.h: In function 'nn_neg_c':
arch/inline/nn_linear_x86_64_core2.h:318: warning: string length '561' is greater than the length '509' ISO C90 compilers are required to support

etc.

All division functions declared in zz.h are documented as to round toward minus infinity. Thus 1 / -2 == -0.5 should round to -1. However, the following program prints '0' and not the expected '-1':

#include "bsdnt/zz.h"
int main(void) {
  zz_t one, minus_two, quot;
  zz_init(one); zz_init(minus_two); zz_init(quot);
  zz_set_str(one, "1");
  zz_set_str(minus_two, "-2");
  zz_div(quot, one, minus_two);
  zz_print(quot);
}

Using zz_divrem instead of zz_div gives the same result.

nn_mul_kara sometimes violates the "bm >= cm" constraint of nn_add_c, potentially leading to invalid memory reads and incorrect results.

The values from this stack trace reveal the issue (i.e. these input parameters to nn_mul_kara seem to meet its input assumptions, but cause a call to nn_add_c that violate nn_add_c's input assumptions):

    frame #4: 0x0000000100034e14 t-nn_subquadratic`nn_add_c(a=0x0000616000007c40, b=0x0000616000007c40, bm=40, c=0x00007fff5fbfe9a0, cm=41, ci=0) + 100 at nn.h:333
    frame #5: 0x0000000100034bb3 t-nn_subquadratic`nn_mul_kara(p=0x0000616000007ba0, a=0x0000613000001020, m=39, b=0x00006110000011e0, n=21) + 4531 at nn_subquadratic.c:63
    frame #6: 0x0000000100002176 t-nn_subquadratic`test_mul_kara + 2710 at t-nn_subquadratic.c:59

Adding ASSERT(bm >= cm) to nn_add_c caused tests failed in multiple places; I'm not sure if nn_mul_kara is the only function violating nn_add_c's input assumptions.