René Scharfe writes:
> Am 09.08.2017 um 19:47 schrieb Junio C Hamano:
>> René Scharfe writes:
>>
>>> There could be any characters except NUL and LF between the 4096 zeros
>>> and "0$" for the latter to match wrongly, no? So there are 4095
>>> opportunities for the
Am 09.08.2017 um 19:47 schrieb Junio C Hamano:
> René Scharfe writes:
>
>> There could be any characters except NUL and LF between the 4096 zeros
>> and "0$" for the latter to match wrongly, no? So there are 4095
>> opportunities for the misleading pattern in a page, with
Hi all,
On Wed, 9 Aug 2017, David Coppa wrote:
> On Wed, Aug 9, 2017 at 4:15 PM, René Scharfe wrote:
> > Am 09.08.2017 um 08:15 schrieb René Scharfe:
> >> Am 09.08.2017 um 07:29 schrieb Junio C Hamano:
> >>> René Scharfe writes:
> >>>
> Am 09.08.2017 um 00:26
René Scharfe writes:
> There could be any characters except NUL and LF between the 4096 zeros
> and "0$" for the latter to match wrongly, no? So there are 4095
> opportunities for the misleading pattern in a page, with probabilities
> like this:
>
> 0$
Am 09.08.2017 um 18:07 schrieb Junio C Hamano:
> René Scharfe writes:
>
>>> In the face of unreliable segfaults we need to reverse our strategy,
>>> I think. Searching for something not in the buffer (e.g. "1") and
>>> considering matches and segfaults as confirmation that the bug
René Scharfe writes:
>> In the face of unreliable segfaults we need to reverse our strategy,
>> I think. Searching for something not in the buffer (e.g. "1") and
>> considering matches and segfaults as confirmation that the bug is
>> still present should avoid any false positives.
On Wed, Aug 9, 2017 at 4:15 PM, René Scharfe wrote:
> Am 09.08.2017 um 08:15 schrieb René Scharfe:
>> Am 09.08.2017 um 07:29 schrieb Junio C Hamano:
>>> René Scharfe writes:
>>>
Am 09.08.2017 um 00:26 schrieb Junio C Hamano:
> ... but in the meantime, I think
Am 09.08.2017 um 08:15 schrieb René Scharfe:
> Am 09.08.2017 um 07:29 schrieb Junio C Hamano:
>> René Scharfe writes:
>>
>>> Am 09.08.2017 um 00:26 schrieb Junio C Hamano:
... but in the meantime, I think replacing the test with "0$" to
force the scanner to find either the
Am 09.08.2017 um 07:29 schrieb Junio C Hamano:
> René Scharfe writes:
>
>> Am 09.08.2017 um 00:26 schrieb Junio C Hamano:
>>> ... but in the meantime, I think replacing the test with "0$" to
>>> force the scanner to find either the end of line or the end of the
>>> buffer may be a
René Scharfe writes:
> Am 09.08.2017 um 00:26 schrieb Junio C Hamano:
>> ... but in the meantime, I think replacing the test with "0$" to
>> force the scanner to find either the end of line or the end of the
>> buffer may be a good workaround. We do not have to care how many of
>>
Am 09.08.2017 um 00:26 schrieb Junio C Hamano:
> Junio C Hamano writes:
>
>> So I find Dscho's concern quite valid, even though I do believe you
>> when you say the code somehow segfaults. I just can not tell
>> how/why it would segfault, though---it is possible that
Am 09.08.2017 um 00:09 schrieb Junio C Hamano:
> René Scharfe writes:
>
>> Am 08.08.2017 um 16:49 schrieb Johannes Schindelin:
>>> Hi René,
>>>
>>> On Tue, 8 Aug 2017, René Scharfe wrote:
>>>
OpenBSD's regex library has a repetition limit (RE_DUP_MAX) of 255.
That's the
Junio C Hamano writes:
> So I find Dscho's concern quite valid, even though I do believe you
> when you say the code somehow segfaults. I just can not tell
> how/why it would segfault, though---it is possible that regexec()
> implementation is stupid and does not realize that
René Scharfe writes:
> Am 08.08.2017 um 16:49 schrieb Johannes Schindelin:
>> Hi René,
>>
>> On Tue, 8 Aug 2017, René Scharfe wrote:
>>
>>> OpenBSD's regex library has a repetition limit (RE_DUP_MAX) of 255.
>>> That's the minimum acceptable value according to POSIX. In t4062 we
Am 08.08.2017 um 16:49 schrieb Johannes Schindelin:
> Hi René,
>
> On Tue, 8 Aug 2017, René Scharfe wrote:
>
>> OpenBSD's regex library has a repetition limit (RE_DUP_MAX) of 255.
>> That's the minimum acceptable value according to POSIX. In t4062 we use
>> 4096 repetitions in the test "-G
Hi René,
On Tue, 8 Aug 2017, René Scharfe wrote:
> OpenBSD's regex library has a repetition limit (RE_DUP_MAX) of 255.
> That's the minimum acceptable value according to POSIX. In t4062 we use
> 4096 repetitions in the test "-G matches", though, causing it to fail.
>
> Do the same as the test
OpenBSD's regex library has a repetition limit (RE_DUP_MAX) of 255.
That's the minimum acceptable value according to POSIX. In t4062 we use
4096 repetitions in the test "-G matches", though, causing it to fail.
Do the same as the test "-S --pickaxe-regex" in the same file and search
for a single
17 matches
Mail list logo