mIRC Homepage
Posted By: Wims PCRE error at compile & exec time - 18/08/19 04:06 PM
When you do $regex(test,expression), mIRC passes that expression to pcre_compile2(), and if compilation fails, mIRC store in $regerrstr a string corresponding to the error (given by pcre).

When you do $regex(test,??) pcre_compile2()/$regerrstr returns "nothing to repeat", which is correct.

After a pattern is compiled, it has to be executed via pcre_exec().

The PCRE demo code shows that after an error from pcre_compile (or pcre_compile2 really), you should not be trying to execute with pcre_exec(), which mIRC seems to be doing in this case, because $regex(test,??) returns -14, an error from pcre_exec().

Note that -14's error description does not match this context and that mIRC reports -14 for some others error reported by pcre_compile2(), ex: $regex(test,(?<=a*))

While I believe this is wrong from a programmer point of view, in practice, nobody uses $regerrstr, (which was undocumented and only found recently) to invalidate a regex match where $regex would have returned a non negative value (including 0 for no match, which doesn't mean there was an error).

There's no real relationship between pcre_compile() and pcre_exec; in practice, I believe that $regex returning a negative value in this case is much more useful and unlikely to surprise scripter and break scripts checking the returned value of $regex.

I was wondering if mIRC was smartly doing this on purpose or if this was just the result of using pcre_exec()?

Again, remember that returning 0 for $regex() would mislead scripters to think there was no match when an error actually occured, because scripters have not been trained to use $regstrerr, so I don't think $regex should return 0, I think it should return a negative value because the compilation failed and $regex kind of has the responsibility to provide an error for both compile/exec functions. Error codes for the exec() function go up to -32, pcre is a stable project with no new feature added to it (only in pcre2) so maybe returning a negative value larger than -32 (well, smaller then) could be a way to indicate to scripters that an error occured at compile time, in which case we could check $regerrstr anyway. Again this is according to the fact that people are not using $regerrstr currently.
Posted By: Khaled Re: PCRE error at compile & exec time - 18/08/19 06:17 PM
The reason for this is that $regex() can fail for many reasons not related to PCRE. In the original implementation, the PCRE code was basic enough that this was not the case. But as it became more complicated, many other error contexts arose. To maintain backwards compatibility, it continued to return the execution error if there was one. But it defaults to PCRE_ERROR_INTERNAL in most other failure cases. It also returns error values from other PCRE calls. So the returned error value can actually be due to a number of APIs and contexts. It was never documented because of this. The most you can depend on with the return value is that if it is negative, it indicates an error.
Posted By: Wims Re: PCRE error at compile & exec time - 18/08/19 06:56 PM
On purpose it is, thanks.
Posted By: Wims Re: PCRE error at compile & exec time - 18/08/19 08:50 PM
Are there/what are the others negative value that can be returned by $regex which aren't related to PCRE?
© mIRC Discussion Forums