On Fri, Apr 24, 2020 at 04:52:33PM +0100, [email protected] 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
signature.asc
Description: PGP signature
-- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
