P.S. it would be a nice addition if pcre: tables could opt into PCRE2's
UTF mode via a /u inline flag, the way native PCRE already spell it.
Today . and its quantifiers count bytes, with no way to switch to code
points, so any length- or content-rule over UTF-8 data can only reason
in bytes. For the length guard in this thread that's actually what I
want, so it's not a blocker — but for rules that genuinely need
character semantics it would help.
Worth noting the current handling makes u a natural letter to claim: an
unrecognized flag isn't rejected, it's skipped with a warning — so
/(.{300})/u today drops the whole rule (and, inside an if … ENDIF,
orphans the ENDIF) rather than erroring. That fail-open behavior is its
own small surprise, independent of the UTF question.
Regards,
Dmytro Alieksieiev
DevOps Engineer
On 16/07/2026 01:10, Dmytro Alieksieiev wrote:
To quantify it, I placed a four-byte character (😅, F0 9F 98 85)
across the 300-byte boundary at each alignment: three of the four
offsets produce a query error, and only the alignment where the
character ends exactly at byte 300 survives.
_______________________________________________
Postfix-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
