gmp v4.2: misc. bugs and flaws

[Torbjorn Granlund]

ThMO <thmo-13 at gmx.de> writes:

  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
  
Thanks, fixed for future releases.  (4.1.4 also had dubious numbers,
as it happens.)

  · 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 #
  
Thanks, fixed.

  · 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)
  
You might want to use the distclean target for that.

  · 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
  
You need to be more clear here with what behaviour you see and
what behaviour you think would be correct.

Notice also that it might be hard to change the (fringe) behaviour of
this function, since it might hurt backward compatibility.

  · 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
  
If you check the manual, you'll see that "reentrant" is actually
exactly what you get by default.  (We might want to clarify things
that we don't any longer alloca huge blocks.)

  · 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...

It is a known problem that our Makefiles are not resistant to
incorrect changes.
  
  · 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
  
I disagree.  The current defaults are the best ones, IMHO.

-- 
Torbjörn