This is on freebsd13.0/arm64/rpi4
A problem arising from milter-regex. This fails to accept known-good
regular expressions, directly taken from a working i386 system.
I believe the problem lies in the regex library, as a test program fails
to compile regular expressions that contain backslashed special
characters:
The salient chunk of my test program is
regex_t re;
if( regcomp( &re, argv[1], REG_ICASE ) ) {
printf("bad re\n");
which works on "simple" things:
# ./a '123' 'abc123def'
re <<123>> string <<abc123def>>
matching:- <<123>>
but fails on \s and \t etc:
# ./a '\s' 'abc def'
re <<\s>> string <<abc def>>
bad re
although this also works # ./a '\\' 'abc\def'
re <<\\>> string <<abc\def>>
matching:- <<\>>
(test program takes the re and a test string as its two args)
I'd not be surprised if this is another char <==> int problem, but the
regex stuff is a tad more complex than spfmilter was.
Can anyone check this out please?
This is on freebsd13.0/arm64/rpi4
A problem arising from milter-regex. This fails to accept known-good
regular expressions, directly taken from a working i386 system.
I believe the problem lies in the regex library, as a test program fails
to compile regular expressions that contain backslashed special characters:
but fails on \s and \t etc:
# ./a '\s' 'abc def'
re <<\s>> string <<abc def>>
bad re
On Thu, 03 Feb 2022 15:52:47 +0000, Mike Scott wrote:.....
This is on freebsd13.0/arm64/rpi4
A problem arising from milter-regex. This fails to accept known-good
regular expressions, directly taken from a working i386 system.
I believe the problem lies in the regex library, as a test program fails
to compile regular expressions that contain backslashed special
characters:
The salient chunk of my test program is
regex_t re;
if( regcomp( &re, argv[1], REG_ICASE ) ) {
printf("bad re\n");
On the arm64 box (fbsd 13.0), I get logged:
parse_ruleset: /usr/local/etc/milter-regex.conf:196: regcomp:
^\s*Fwd.?\s*$: trailing backslash (\)
On the i386 (running fbsd 11.4), the file compiles happily in full.
Hence my supposition about errors in the regex library.
What are "\s" and "\t" supposed to mean? In traditional regular
expressions, they have no meaning.
On 03/02/2022 18:23, Christian Weisgerber wrote:
What are "\s" and "\t" supposed to mean? In traditional regular
expressions, they have no meaning.
I'm not sure how many decades ago you are claiming for traditional reg
ex, but \s and \t have been any white space and tab for a long as I can remember.
On 03/02/2022 18:23, Christian Weisgerber wrote:
What are "\s" and "\t" supposed to mean? In traditional regular expressions, they have no meaning.
I'm not sure how many decades ago you are claiming for traditional reg
ex, but \s and \t have been any white space and tab for a long as I can remember.
OTOH, Perl-compatable regular expressions recognize \s and \t as having special meanings,
On 04-02-2022 22:32, Lew Pitcher wrote:[snip]
OTOH, Perl-compatable regular expressions recognize \s and \t as having
special meanings,
Not only pcre, also enhanced or extended. I don't have FreeBSD here but
this is from the MacOS man page which is based on BSD: (conclusion below that)
-----
ENHANCED FEATURES
When the REG_ENHANCED flag is passed to one of the regcomp()
variants, additional features are activated.
So in practice it turns out that, using the built-in BSD-based grep on
MacOS without any flags, it does support both \s and \t.
The salient chunk of my test program is
regex_t re;
if( regcomp( &re, argv[1], REG_ICASE ) ) {
printf("bad re\n");
On 2022-02-03, Mike Scott <usenet.16@scottsonline.org.uk.invalid> wrote:
This is on freebsd13.0/arm64/rpi4
A problem arising from milter-regex. This fails to accept known-good
regular expressions, directly taken from a working i386 system.
I think your arm64 system is at a different revision of FreeBSD
than your i386 one.
I believe the problem lies in the regex library, as a test program fails
to compile regular expressions that contain backslashed special characters: >>
but fails on \s and \t etc:
# ./a '\s' 'abc def'
re <<\s>> string <<abc def>>
bad re
What are "\s" and "\t" supposed to mean? In traditional regular
expressions, they have no meaning. In that case, the '\' used to
be ignored, i.e., they were equivalent to plain "s" and "t".
However, that was changed in this commit...
regex(3): Interpret many escaped ordinary characters as EESCAPE https://cgit.freebsd.org/src/commit/lib/libc/regex?id=adeebf4cd47c3e85155d92f386bda5e519b75ab2
... so such sequences would now result in an error.
Subsequently, some GNU extensions have been added that give new
meaning to "\s" but not to "\t".
Sysop: | Coz |
---|---|
Location: | Anoka, MN |
Users: | 2 |
Nodes: | 4 (0 / 4) |
Uptime: | 35:10:42 |
Calls: | 141 |
Files: | 5,058 |
Messages: | 220,739 |