Hi I farther tested the issue in context. \U, \u are consistent and will fail
whether I supply any text to match or not.
the \l does not fail as I've already shown and if I provide an input text it
will match alright.
the \L behavior changes when I provide an input text to match. Please observe
the behavior below where the \L produces an initial, uncalled for 'No Match'
and then it happily does match. It seems to be a sort of a bug in the behavior
of \l and \L that is triggered by the EBCDIC environment rather than caused by
it.
I believe that this is the most serious open issue in my side. Once resolved,
I will try to create a standard, composite test file (or files) and once done
to contribute it.
Input file >>>>>>>>>>>>>>>>>>
< forbid 8W
/\l/I
/\L/I
/\l/I l/\L/I l
/\N{name}/I
/\u/I
/\U/I
/\u/I L/\U/I L
<<<<<<<<<<<<<<<<< end input file
Output File>>>>>>>>>>>>>>>>>>>>>
< forbid 8W
/\l/ICapturing subpattern count = 0No optionsFirst char = 'l'No need char
/\L/IFailed: PCRE does not support \L, \l, \N{name}, \U, or \u at offset 1
/\l/ICapturing subpattern count = 0No optionsFirst char = 'l'No need char l
0: l/\L/INo match l 0: l
/\N{name}/IFailed: PCRE does not support \L, \l, \N{name}, \U, or \u at offset 1
/\u/IFailed: PCRE does not support \L, \l, \N{name}, \U, or \u at offset 1
/\U/IFailed: PCRE does not support \L, \l, \N{name}, \U, or \u at offset 1
/\u/IFailed: PCRE does not support \L, \l, \N{name}, \U, or \u at offset 1
<<<<<<<<<<<<<<<<End Output File
Ze'ev Atlas
--
## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
