On Thu, Sep 11, 2014 at 12:10 PM, Paul Eggert wrote:
> On 09/11/2014 11:37 AM, Jim Meyering wrote:
>>
>> Would you mind adding a test to trigger that one?
>
> Ordinarily I would have done that already but this -P stuff is so buggy and
> slow that I got discouraged. (If we keep having trouble with
On 2014-09-11 10:07:49 -0700, Paul Eggert wrote:
> Vincent Lefevre wrote:
> >I've just reported a new Debian concerning the performance problem.
>
> It's not clear from http://bugs.debian.org/761157 that the performance
> problem occurs only with -P, but I assume that's what is meant.
It's specif
On 09/11/2014 11:37 AM, Jim Meyering wrote:
Would you mind adding a test to trigger that one?
Ordinarily I would have done that already but this -P stuff is so buggy
and slow that I got discouraged. (If we keep having trouble with -P I
may start lobbying to remove it) Anyway, I gave it a
On Thu, Sep 11, 2014 at 10:07 AM, Paul Eggert wrote:
> Vincent Lefevre wrote:
>
>> I've just reported a new Debian concerning the performance problem.
>
>
> It's not clear from http://bugs.debian.org/761157 that the performance
> problem occurs only with -P, but I assume that's what is meant.
>
>
Vincent Lefevre wrote:
I've just reported a new Debian concerning the performance problem.
It's not clear from http://bugs.debian.org/761157 that the performance
problem occurs only with -P, but I assume that's what is meant.
Since this is a performance bug with PCRE, I suggest moving the D
Santiago wrote:
Another solution would be to don't check if binary files are valid
(passing PCRE_NO_UTF8_CHECK to pcre_exec), but I don't know if that'd
avoid security holes
It wouldn't. (We already tried it.)
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subje
El 16/08/14 a las 18:26, Vincent Lefevre escribió:
> On 2014-08-16 16:01:27 +0200, Santiago wrote:
> > Workaround attached. It's too slow against binary files, but I haven't
> > found a simpler solution.
>
> To avoid the slowness, I think that it would be better to detect
> (directly, not via PCRE
On 2014-08-16 16:01:27 +0200, Santiago wrote:
> Workaround attached. It's too slow against binary files, but I haven't
> found a simpler solution.
To avoid the slowness, I think that it would be better to detect
(directly, not via PCRE) invalid UTF-8 sequences and replace them
by null bytes *in-pl
El 14/08/14 a las 14:33, Paul Eggert escribió:
> Vincent Lefevre wrote:
> >On input, using null bytes may be better if one wants to be able to
> >match real replacement characters without false positives.
>
> Maybe, though this is no place to get fancy. It's simple to tell users "an
> invalid byt
Vincent Lefevre wrote:
On input, using null bytes may be better if one wants to be able to
match real replacement characters without false positives.
Maybe, though this is no place to get fancy. It's simple to tell users
"an invalid byte acts like '?'". Simple is good.
Anyway, this is a ma
10 matches
Mail list logo
