Author: ph10 Date: To: Petr Pisar CC: pcre-dev Subject: Re: [pcre-dev] PCRE2 10.35-RC1 testing release is available
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).
> 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.
