Thanks for the patch. In fact I was intending to do an upload yesterday, and
held off when I saw this message. Looking at the bugs you filed on PCRE and
glib (thanks), it looks like I should go ahead with a pcre 8.35 release, and
glib will have to deal with this, do you agree?
On 20 Jul 2014,
On Mon, 21 Jul 2014 at 22:18:47 +0100, Mark Baker wrote:
Thanks for the patch. In fact I was intending to do an upload yesterday,
and held off when I saw this message. Looking at the bugs you filed on
PCRE and glib (thanks), it looks like I should go ahead with a pcre 8.35
release, and glib
On Thu, 17 Jul 2014 at 10:38:24 +0100, Simon McVittie wrote:
If min gets larger than 214748365 (slightly more than 2^31 / 10) in any
given iteration, then the next multiplication by 10 is a signed integer
overflow, which is formally undefined behaviour in C.
This was already reported as
On Sun, 20 Jul 2014 at 16:07:06 +0100, Simon McVittie wrote:
This was already reported as http://bugs.exim.org/show_bug.cgi?id=1463
and fixed upstream as part of r1472. However, the upstream fix did not
update the expected output, so the tests still fail.
The upstream fix did in fact update
On Sun, 20 Jul 2014 at 18:56:01 +0100, Simon McVittie wrote:
However, I haven't done so yet, because the updated
pcre3 seems to trigger a test failure in the pcre consumer I'm mainly
interested in (GLib), and I want to be sure that these changes aren't
what's to blame for that.
They are
tags 751828 + patch
retitle 751828 pcre3: FTBFS: test failure: no longer produces number too big
in {} quantifier
found 751828 1:8.35-2
thanks
On Wed, 18 Jun 2014 at 11:38:11 -0300, Mauricio Faria de Oliveira wrote:
/a{}/I
-Failed: number too big in {}
Package: src:pcre3
User: debian-powe...@lists.debian.org
Usertags: ppc64el
This bug also affects ppc64el (no JIT).
Documenting the same pattern as comment above, from test-suite.log:
[...]
FAIL: RunTest
=
[...]
Testing 8-bit library
7 matches
Mail list logo
