gmp v4.2: misc. bugs and flaws

[ThMO]

Hello Torbjörn,

first of all, THX for responding.

>   · intalled library versions aren't correctly numbered:
> [...] 
> Thanks, fixed for future releases.  (4.1.4 also had dubious numbers,
> as it happens.)

I've upgraded gmp from v3.1.1 -> v4.1.4, so for this upgrade the
versioning was O.K.


>   · it would be nice, if the generated binaries and C files be deleted,
>     while invoking `make clean', namely:
> [...]
> You might want to use the distclean target for that.

Not really, since the configuration of the package is deleted too,
which might be tedious and will take it's sweet time on slower
computers, if it need to be re-compiled again...


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

1.)
# ./mpbug 10 +13
-lgmp: str= "+13", n= 0, base= 10, res= -1
mpbug: str= "+13", n= 13, base= 10, res= 0

mpz_set_str() signals an error because of the leading `+' sign.

2.)
# ./mpbug 10 "  -000 13"
-lgmp: str= "  -000 13", n= -13, base= 10, res= 0
mpbug: str= "  -000 13", n= 0, base= 10, res= -1
 failed at:        ^

mpz_set_str() successfully return -13, where it should return an
error, like my wrapper function does.
(the caret points to the white-space between the last 0 and the 1)

3.)
# ./mpbug 0 0x
-lgmp: str= "0x", n= 0, base= 0, res= 0
mpbug: str= "0x", n= 0, base= 0, res= -1
 failed at:  ^

mpz_set_str() successfully return 0, where it should return an
error, like my wrapper function does - just compare this with
the C library strtol()...

4.)
# ./mpbug 16 0xabc1262
-lgmp: str= "0xabc1262", n= 0, base= 16, res= -1
mpbug: str= "0xabc1262", n= 180097634, base= 16, res= 0

mpz_set_str() returns an error, where it should return the converted
hexadecimal number, since the given base signifier 0x corresponds to
the given base 16 - again analogous to strtol()...

Hopefully the above explanations makes it somewhat clearer?


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

This might be an argument, though.
But let me suggest the following: I could slightly change my wrapper
routine to behave in some more respect to strtol() - currently I do
force an error, if the given number isn't correctly null-terminated -
and we could call it mpz_strtoz(), converting the string like strtol()
does and returning a pointer to the offending character, which stops
conversion, which it does already, so users could use this conversion
function in order to convert digits, like they're getting used from
using strtol() already?
But surely you'll get asked for some mpf_strtod()...


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

If this change is an incorrect one is arguable, but YMMV.
But this could be fixed in a simple way, in that the `all' target
first lists a target like e.g. `libs', which will build the static
and/or shared libraries prior before recursing into the several
sub-directories, thereby making it possible, to automatically build
the various demo-programs, if so requested...
Not a big deal of a change IMHO, but again YMMV.


CU Tom.
(Thomas M.Ott)
Germany