Any ideas on its disappearance in v5.26 (and later versions)?
The condition that triggers the warning (in MM_Any.pm) is:
if ($self->{ABSTRACT} && $self->{ABSTRACT} =~ m![[:cntrl:]]+!) { # war
+ning is given }
That condition is still there in perl-5.26, and I can't see any change to it.
Perhaps a change in the regex engine was introduced in 5.26.
Are you able to verify that the abstract does, in fact, =~ m![[:cntrl:]]+! in perl-5.20 but not in perl-5.26 and later ?
The question would then be "Did that change in the regex fix a problem, or did it create one ?".
From your description of the ABSTRACT, I'm not sure that it does actually contain any control characters.
Update:
I'm having no luck in reproducing your issue at all (on Windows).
I find that it's the same behaviour from 5.20 onwards. For me, the presence of either chr(10) ("\n") or chr(13) ("\r") always results in a match.
What's the perl -V ?
Cheers,
Rob
| [reply]
[d/l]
[select] |
G'day Rob,
"Are you able to verify that the abstract does, in fact, =~ m![[:cntrl:]]+! in perl-5.20 but not in perl-5.26 and later ?"
The short answer is "Yes".
The longer answer is tad more complicated because the code that would demonstrate this is from $work.
I basically ran a GitLab CI/CD pipeline with 14 jobs.
Each job used a different docker Perl image: perl:5.16 to perl:5.36
plus three others to cover deltas that indicated some backward-incompatibility in subversions
(follow the footnote link in the OP for more details).
The output from those jobs only showed the warning in v5.20 to v5.24.
There was only the one source Perl module.
It was very old, created long before I joined the company, and every line ended with a CR-LF.
When I removed the CR, the warnings disappeared for all the v5.20 to v5.24 jobs;
the output for the remaining jobs was unchanged.
I suspect the module was originally written on an MSWin platform for ActivePerl/Strawberry Perl/whatever
and then migrated to a Linux box without any line-ending conversions (but that's very much a guess).
And, as a further guess, the way $self->{ABSTRACT} is assigned its value, has something to do with it.
| [reply]
[d/l]
[select] |
And, as a further guess, the way $self->{ABSTRACT} is assigned its value, has something to do with it.
It's all very strange.
I, in fact, did get to wonder whether the change was in the assignment of $self->{ABSTRACT}, and *not* in the behaviour of $self->{ABSTRACT} =~ m![[:cntrl:]]+!
However, I didn't really look at how the former was being assigned.
If I could reproduce the issue I reckon I'd be wanting to understand it.
But I can't reproduce it ... so it's really not all that important to me. (I guess I just find it "intriguing" rather than "important".)
To satisfy my own curiosity, I fiddled about with the following script, on both Linux and Windows:
use strict;
use warnings;
my $count = 0;
for my $s(chr(13) . chr(10),
chr(10) . chr(13),
chr(10) ,
chr(13) ,
'0' . chr(13) . chr(10),
'0' . chr(10) . chr(13),
'0' . chr(10) ,
'0' . chr(13) , ) {
$count++;
print "$count match\n" if ($s && $s =~ m![[:cntrl:]]+!);
}
But it just outputs:
1 match
2 match
3 match
4 match
5 match
6 match
7 match
8 match
on every perl I run it on.
So I don't understand how a lone \r is being treated differently to a lone \n or \r\n in some cases for you.
Cheers,
Rob
| [reply]
[d/l]
[select] |
