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. Philip -- Philip Hazel -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
