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 misleading pattern in a page
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 probabilities
>> like t
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 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 probabilities
> like this:
>
> 0$ 1/256 * 2/256
>
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 is
>>> still p
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. Right?
>
> An
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 replacing the test with "0$"
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 end of line or
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 good workaround
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
>> random bytes a
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 regexec()
>> implementation
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 minimum acceptab
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 it can return early
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 use
>>> 4096 r
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 match
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 "
16 matches
Mail list logo