Ciao,
Il 2021-09-18 10:07 Torbjörn Granlund ha scritto:
I suppose that, in this case, as my fix has problems with nails, this
Your fix also aborts, instead of returning 0.
might be a better patch. An UNLIKELY(...) might have a place here,
though.
I commited the patch, adding UNLIKELY to
Ciao,
Il 2021-09-16 23:27 Torbjörn Granlund ha scritto:
Going from byte count to bit count to limb count is non-trivial without
risking overflow, even if the end result will typically be smaller than
the incoming byte count (assuming we're not using gmp/asl.h with tiny
Yes, but, should we
Hi Torbjörn,
I confirm your fix works on gcc45:
zimmerma@gcc45:~/ecm$ gcc -I$HOME/include test.c $HOME/lib/libgmp.a
zimmerma@gcc45:~/ecm$ ./a.out
XXX 2d65200d 0b594804
gmp: overflow in mpz type
Aborted
Thanks,
Paul
___
gmp-bugs mailing list
Vincent Lefevre writes:
In mpz/inp_raw.c, I think that abs_csize*8 yields an integer overflow
on large sizes.
Indeed.
Going from byte count to bit count to limb count is non-trivial without
risking overflow, even if the end result will typically be smaller than
the incoming byte count
On 2021-09-15 17:34:01 +0200, Vincent Lefevre wrote:
> On 2021-09-15 17:05:42 +0200, Paul Zimmermann wrote:
> > sorry the test_dummy2.save is attached. It was generated by (under /bin/sh,
> > not /bin/bash):
> >
> > echo -e "\n\r\n\r# this is a comment line and should be ignored" >
> >
On 2021-09-15 17:05:42 +0200, Paul Zimmermann wrote:
> sorry the test_dummy2.save is attached. It was generated by (under /bin/sh,
> not /bin/bash):
>
> echo -e "\n\r\n\r# this is a comment line and should be ignored" >
> test_dummy2.save
I can reproduce the segfault only with a 32-bit ABI.
sorry the test_dummy2.save is attached. It was generated by (under /bin/sh,
not /bin/bash):
echo -e "\n\r\n\r# this is a comment line and should be ignored" >
test_dummy2.save
Paul
test_dummy2.save
Description: Binary data
___
gmp-bugs mailing list
On 2021-09-15 16:13:55 +0200, Torbjorn Granlund wrote:
> I tried to reproduce this on several systems. I failed; mpz_inp_raw
> returns 0 for me as it should.
>
> I cannot be sure I got test_dummy2.save right. I did include the line
> that asked to be ignored. Should I have ignored it? I added
I tried to reproduce this on several systems. I failed; mpz_inp_raw
returns 0 for me as it should.
I cannot be sure I got test_dummy2.save right. I did include the line
that asked to be ignored. Should I have ignored it? I added LF at each
appparent line end, including the ignore line.
--
> OK, so you deliberately sen d junk to mpz_inp_raw. That is fine, but it
> was not clear from your report.
it was not completely deliberate. The long story is that I tested "make check"
of GMP-ECM on gcc45 with some recent merge request, and with /bin/sh the
command echo -e "..." > xxx did put
Paul Zimmermann writes:
I was thus expecting it to return 0 in case of an invalid file.
OK, so you deliberately sen d junk to mpz_inp_raw. That is fine, but it
was not clear from your report.
--
Torbjörn
Please encrypt, key id 0xC8601622
___
Dear Torbjörn,
> $ cat test_dummy2.save
> -e
>
> # this is a comment line and should be ignored
>
> You do understand that mpz_inp_raw expects a binary file with a size
> field followed by that many byytes of data, don't you?
>
> The file contents above make no sense.
the
Paul Zimmermann writes:
$ cat test_dummy2.save
-e
# this is a comment line and should be ignored
You do understand that mpz_inp_raw expects a binary file with a size
field followed by that many byytes of data, don't you?
The file contents above make no sense.
--
Torbjörn
Please
Hi,
with gmp-6.2.1 and the following program:
zimmerma@gcc45:~/ecm$ cat test.c
#include
#include
#include
main()
{
mpz_t s;
FILE *file;
int ret;
mpz_init (s);
file = fopen ("test_dummy2.save", "rb");
ret = mpz_inp_raw (s, file);
}
I get a Segmentation fault on gcc45 with
14 matches
Mail list logo
