Re: [pcre-dev] PCRE2 10.35-RC1 testing release is available

On Fri, Apr 24, 2020 at 04:52:33PM +0100, ph10@??? wrote:
> On Fri, 24 Apr 2020, Petr Pisar via Pcre-dev wrote:
>
> > I think it's a mistake in PCRE2 code.
>
> Oh, I was looking at something completely different. The PCHARS and
> PCHARSV macros print character strings in different bit-widths by
> calling appropriate width-specific functions. In many cases they are
> passed a positive length. However, when called to print the string from
> (*MARK) the length is negative, because the actual length is in the code
> unit that precedes the (*MARK) string pointer. My previous attempt just
> tried to make another variable to avoid using [-1] as a suffix. I have
> now realized that the macros allow for an offset to be specified (you
> specify a,b,l and it passes a+b as the pointer argument). For all the
> (*MARK) cases it was using p,0,-1. I have now changed it to pass
> p,-1,-1 and adjusted the code in the 8/16/32-bit output functions
> accordingly. (If the length is negative they pick it up from the first
> code unit.) I hope this will satisfy your compiler (patch committed).
>
Thanks. I confirm it fixes the warnings.

> > I focused on the first warning from this code:
>
> I don't *think* that is the issue, but thank you very much for doing so
> much investigation. I can't see how "length" can be negative in the code
> that you cite.
>
You are right. pcre2_substring_copy_bynumber() returns before updating the
lenght variable if the matched string does not fit into copybuffer[] that is
really short (256 code points).

-- Petr