gmp v4.2: misc. bugs and flaws

[ThMO]

Hello folks,

I've noticed some bugs and flaws, which needs some correction, namely:

· intalled library versions aren't correctly numbered:
  · v4.1.4:
    · libgmp.so.3.3.3
    · libmp.so.3.1.7
  · v4.2:
    · libgmp.so.3.3.0
    · libmp.so.3.1.4
  -> one would expect, that newer versions of this library do install
     libraries with higher version numbers, since `ldconfig' will use
     the *older* libraries, unless removed first

· the declaration of the gmp_vasprintf() inside the texinfo manual is
  wrong, since it's first parameter is of type char **
  (I've reported this already last year in october...)

# snip for diff #
--- gmp-4.2/doc/gmp.texi.orig   2006-03-22 09:39:17.000000000 +0100
+++ gmp-4.2/doc/gmp.texi        2006-03-29 21:52:53.000000000 +0200
@@ -5805,7 +5805,7 @@
 @end deftypefun
 
 @deftypefun int gmp_asprintf (char **@var{pp}, const char *@var{fmt}, @dots{})
- at deftypefunx int gmp_vasprintf (char *@var{pp}, const char *@var{fmt}, va_list @var{ap})
+ at deftypefunx int gmp_vasprintf (char **@var{pp}, const char *@var{fmt}, va_list @var{ap})
 Form a null-terminated string in a block of memory obtained from the current
 memory allocation function (@pxref{Custom Allocation}).  The block will be the
 size of the string and null-terminator.  The address of the block in stored to
# end of snip for diff #

· it would be nice, if the generated binaries and C files be deleted,
  while invoking `make clean', namely:
  FUCK= mpz/fac_ui.h gen-fac_ui gen-fac_ui_.c fib_table.h gen-fib \
        mpn/fib_table.c gen-fib_.c mp_bases.h gen-bases mpn/mp_bases.c \
        gen-bases_.c mpn/perfsqr.h gen-psqr gen-psqr_.c
  clean: clean-recursive
        $(RM) $(FUCK)

· mpz_set_str(): this function fails several times converting string values
  (I've reported those failures last year in october too, but it seems, it
   wasn't of interest..., although it might be the reason, that the mailing
   list software is unable to handle FWDs correctly...)
  [if some C code is wanted to play with the conversion failures, just drop
   me a note, since the older C code doesn't handle the increased bases]

  now following the failures:
  · mpz_set_str( n, "+13", 10);
    -> an optional `+' sign is *not* an error
  · mpz_set_str( n, "13 ", 10);
    -> trailing white-space *is* an error
  · mpz_set_str( n, "  -000 13", 10);
    -> white-space between digits *is* an error
  · mpz_set_str( n, "0x", 0);
    -> if the given base is 0, which means the base shall be set upon scanning,
       and the base-signifier isn't followed by at least one valid digit, this
       *must* be an error
  · mpz_set_str( n, "0xabc1262", 16);
    -> if base is 2 or 16 *and* the respective base-signifier is given at the
       front of the number, this *is* correct
    the only exception to this rule is octal zero, which is handled correctly

· default values, according to `configure --help' and the configuration re=
  sults differ, e.g. `configure --help' says, that re-entrant temporary
  allocation is the default, but after inspecting the generated config.h
  file, alloca() will be used for temporary storage allocation
  this is fine for me, but not for others - and differs, from what the
  help-screen says

· make ordering: recursing into the demos/calc directory, *before* the
  library has been generated, isn't a good solution, if someone changes
  the Makefile in this sub-directory, in order to built this program...

· some thoughts about automatically select the processor gimmicks, namely
  MMX and SSE stuff, during runtime:
  detecting those features for the processor in question is easy, but checking
  that the underlying OS is able to support them, while running, is very
  difficult, if not to say impossible, in a reliable way, e.g. I've checked
  the gmp library on a friend's computer running a P-III, where the configure
  script accordingly activates SSE, but the underlying OS doesn't support SSE;
  in the best case, the program simply dies, but in the most common case, the
  program simply delivers wrong results (although one time some SSE instructions
  hang the computer, which cried for a hard boot then), so it might be the best
  solution, to always let the user decide at compile time, which gimmicks should
  be used

· and now a compliment - it's good to see, that mpz_millerrabin() can be called
  directly, hoping you'll not decide to hide it in the future...

THX for listening.

CU Tom.
(Thomas M.Ott)
Germany