unwanted warning from diagnostics.pm under -w #11233

p5pRT · 2011-04-04T03:43:56Z

Migrated from rt.perl.org#87726 (status was 'resolved')

Searchable as RT87726$

p5pRT · 2011-04-04T03:43:58Z

From @cpansprout

Sisyphus wrote (at <http://www.nntp.perl.org/group/perl.perl5.porters/2011/04/msg170570.html>):

Hi,

I'm using a blead that I downloaded yesterday. Its 'perl -v' reports 5.14.0.

No problems when run as a normal perl script but, for me, any test file that
uses diagnostics.pm emits
"Use of uninitialized value $1 in concatenation (.) or string at
C:/bleadperl/lib/diagnostics.pm line 403, <POD_DIAG> chunk 1198" when run
under 'dmake test'. (Haven't checked to see whether any other systems and
flavours of make are affected.)

I get the warning even with a test file that contains only:
############
use diagnostics;
print "1..1\n";
print "ok 1\n";
############

Can this be fixed before 5.14 is released ?
If not, I'll just remove 'use diagnostics;' from the Inline test scripts.

Line 403 (and thereabouts):

399: else {
400: $header = $1;
401: while( $header =~ /[;,]\z/ ) {
402: <POD_DIAG> =~ /^\s*(.*?)\s*\z/;
403: $header .= ' '.$1;
404: }
405: }
406:
407: # strip formatting directives from =item line
408: $header =~ s/[A-Z]<(.*?)>/$1/g;

Cheers,
Rob

This is a recent regression, probably from one of my commits. Can this be made into a blocker?

Flags:
category=library
severity=high

Site configuration information for perl 5.13.11:

Configured by sprout at Thu Mar 24 14:02:46 PDT 2011.

Summary of my perl5 (revision 5 version 13 subversion 11) configuration:
Snapshot of: cc13eef
Platform:
osname=darwin, osvers=10.5.0, archname=darwin-thread-multi-2level
uname='darwin pint.local 10.5.0 darwin kernel version 10.5.0: fri nov 5 23:20:39 pdt 2010; root:xnu-1504.9.17~1release_i386 i386 '
config_args='-Dusedevel -de -Duseithreads -Doptimize=-g'
hint=recommended, useposix=true, d_sigaction=define
useithreads=define, usemultiplicity=define
useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
use64bitint=undef, use64bitall=undef, uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include',
optimize='-g',
cppflags='-no-cpp-precomp -fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
ccversion='', gccversion='4.2.1 (Apple Inc. build 5664)', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='env MACOSX_DEPLOYMENT_TARGET=10.3 cc', ldflags =' -fstack-protector -L/usr/local/lib'
libpth=/usr/local/lib /usr/lib
libs=-ldbm -ldl -lm -lutil -lc
perllibs=-ldl -lm -lutil -lc
libc=/usr/lib/libc.dylib, so=dylib, useshrplib=false, libperl=libperl.a
gnulibc_version=''
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' '
cccdlflags=' ', lddlflags=' -bundle -undefined dynamic_lookup -L/usr/local/lib -fstack-protector'

Locally applied patches:

@INC for perl 5.13.11:
/usr/local/lib/perl5/site_perl/5.13.11/darwin-thread-multi-2level
/usr/local/lib/perl5/site_perl/5.13.11
/usr/local/lib/perl5/5.13.11/darwin-thread-multi-2level
/usr/local/lib/perl5/5.13.11
/usr/local/lib/perl5/site_perl
.

Environment for perl 5.13.11:
DYLD_LIBRARY_PATH (unset)
HOME=/Users/sprout
LANG=en_US.UTF-8
LANGUAGE (unset)
LD_LIBRARY_PATH (unset)
LOGDIR (unset)
PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin:/usr/local/bin
PERL_BADLANG (unset)
SHELL=/bin/bash

p5pRT · 2011-04-04T06:51:25Z

From @obra

On Sun 3.Apr'11 at 20:43:58 -0700, Father Chrysostomos wrote:

This is a recent regression, probably from one of my commits. Can this be made into a blocker?

Can we bisect it first? I'd like to know what caused it.

p5pRT · 2011-04-04T06:51:26Z

The RT System itself - Status changed from 'new' to 'open'

p5pRT · 2011-04-04T13:06:01Z

From @cpansprout

On Sun Apr 03 23:51:25 2011, jesse wrote:

On Sun 3.Apr'11 at 20:43:58 -0700, Father Chrysostomos wrote:

This is a recent regression, probably from one of my commits. Can
this be made into a blocker?

Can we bisect it first? I'd like to know what caused it.

commit d50a4f9
Author: Karl Williamson <public@khwilliamson.com>
Date: Sun Feb 27 18:44:43 2011 -0700

Handle [folds] of 0-255 without swashes
...
+=item Perl folding rules are not up-to-date for 0x%x; please use the
perlbug utility to report;
+
+(W regex, deprecated) You used a regular expression with
+case-insensitive matching, and there is a bug in Perl in which the
+built-in regular expression folding rules are not accurate. This may
+lead to incorrect results. Please report this as a bug using the
+"perlbug" utility. (This message is marked deprecated, so that it by
+default will be turned-on.)
+

diagnostics.pm is having trouble parsing that header, it seems.

p5pRT · 2011-04-04T13:06:01Z

From [Unknown Contact. See original ticket]

On Sun Apr 03 23:51:25 2011, jesse wrote:

On Sun 3.Apr'11 at 20:43:58 -0700, Father Chrysostomos wrote:

This is a recent regression, probably from one of my commits. Can
this be made into a blocker?

Can we bisect it first? I'd like to know what caused it.

commit d50a4f9
Author: Karl Williamson <public@khwilliamson.com>
Date: Sun Feb 27 18:44:43 2011 -0700

Handle [folds] of 0-255 without swashes
...
+=item Perl folding rules are not up-to-date for 0x%x; please use the
perlbug utility to report;
+
+(W regex, deprecated) You used a regular expression with
+case-insensitive matching, and there is a bug in Perl in which the
+built-in regular expression folding rules are not accurate. This may
+lead to incorrect results. Please report this as a bug using the
+"perlbug" utility. (This message is marked deprecated, so that it by
+default will be turned-on.)
+

diagnostics.pm is having trouble parsing that header, it seems.

p5pRT · 2011-04-04T14:36:25Z

From @khwilliamson

On 04/04/2011 07:06 AM, Father Chrysostomos via RT wrote:

On Sun Apr 03 23:51:25 2011, jesse wrote:

On Sun 3.Apr'11 at 20:43:58 -0700, Father Chrysostomos wrote:

This is a recent regression, probably from one of my commits. Can
this be made into a blocker?

Can we bisect it first? I'd like to know what caused it.

commit d50a4f9
Author: Karl Williamson<public@khwilliamson.com>
Date: Sun Feb 27 18:44:43 2011 -0700
 Handle \[folds\] of 0\-255 without swashes
...
+=item Perl folding rules are not up-to-date for 0x%x; please use the
perlbug utility to report;
+
+(W regex, deprecated) You used a regular expression with
+case-insensitive matching, and there is a bug in Perl in which the
+built-in regular expression folding rules are not accurate. This may
+lead to incorrect results. Please report this as a bug using the
+"perlbug" utility. (This message is marked deprecated, so that it by
+default will be turned-on.)
+

diagnostics.pm is having trouble parsing that header, it seems.

I'll look into it but have essentially no tuits till the weekend, but it
may not take a lot of tuits. There are other instances in the pod that
have the same syntax . My guess is that it is a combination of the
semi-colon on the =item line with the comma in the (W...) line

p5pRT · 2011-04-04T16:58:03Z

From @tamias

On Mon, Apr 04, 2011 at 08:35:50AM -0600, Karl Williamson wrote:

I'll look into it but have essentially no tuits till the weekend, but it
may not take a lot of tuits. There are other instances in the pod that
have the same syntax . My guess is that it is a combination of the
semi-colon on the =item line with the comma in the (W...) line

That is actually the only instance where a header ends with a semi-colon.
I believe that is the problem.

The relevant code in diagnostic.pm sees the header ends with a
semi-colon, so it reads in the next record from POD_DIAG, looking for
the rest of the header. Then the regex /^\s*(.*?)\s*\z/ fails to
match, because that next record is a multi-line paragraph.

if( $for_item ) { $header = $for_item; undef $for_item }
else {
$header = $1;
while( $header =~ /[;,]\z/ ) {
<POD_DIAG> =~ /^\s*(.*?)\s*\z/;
$header .= ' '.$1;
}
}

Ronald

p5pRT · 2011-04-05T04:32:51Z

From @khwilliamson

On 04/04/2011 10:57 AM, Ronald J Kimball wrote:

On Mon, Apr 04, 2011 at 08:35:50AM -0600, Karl Williamson wrote:

I'll look into it but have essentially no tuits till the weekend, but it
may not take a lot of tuits. There are other instances in the pod that
have the same syntax . My guess is that it is a combination of the
semi-colon on the =item line with the comma in the (W...) line

That is actually the only instance where a header ends with a semi-colon.
I believe that is the problem.

The relevant code in diagnostic.pm sees the header ends with a
semi-colon, so it reads in the next record from POD_DIAG, looking for
the rest of the header. Then the regex /^\s*(.*?)\s*\z/ fails to
match, because that next record is a multi-line paragraph.
  if$ $for\_item $ \{ $header = $for\_item; undef $for\_item \}
  else \{
      $header = $1;
      while$ $header =~ /\[;\,\]\\z/ $ \{
          \<POD\_DIAG>  =~ /^\\s\*$\.\*?$\\s\*\\z/;
          $header \.= ' '\.$1;
      \}
  \}
Ronald

You're right. Removing the semi-colon fixes this. It's not on the 5.14
list, though.

p5pRT · 2011-04-05T05:25:16Z

From @obra

On Mon 4.Apr'11 at 22:31:45 -0600, Karl Williamson wrote:

On 04/04/2011 10:57 AM, Ronald J Kimball wrote:
On Mon, Apr 04, 2011 at 08:35:50AM -0600, Karl Williamson wrote:

I'll look into it but have essentially no tuits till the weekend, but it
may not take a lot of tuits. There are other instances in the pod that
have the same syntax . My guess is that it is a combination of the
semi-colon on the =item line with the comma in the (W...) line

That is actually the only instance where a header ends with a semi-colon.
I believe that is the problem.

The relevant code in diagnostic.pm sees the header ends with a
semi-colon, so it reads in the next record from POD_DIAG, looking for
the rest of the header. Then the regex /^\s*(.*?)\s*\z/ fails to
match, because that next record is a multi-line paragraph.
 if$ $for\_item $ \{ $header = $for\_item; undef $for\_item \}
 else \{
     $header = $1;
     while$ $header =~ /\[;\,\]\\z/ $ \{
         \<POD\_DIAG>  =~ /^\\s\*$\.\*?$\\s\*\\z/;
         $header \.= ' '\.$1;
     \}
 \}
Ronald
You're right. Removing the semi-colon fixes this. It's not on the
5.14 list, though.

Please feel free to commit that.

p5pRT · 2011-04-06T11:04:32Z

From @obra

I'm resolving this ticket, as Karl committed
http://perl5.git.perl.org/perl.git/commit/801eb083

p5pRT · 2011-04-06T11:04:33Z

@obra - Status changed from 'open' to 'resolved'

p5pRT closed this as completed Apr 6, 2011

p5pRT added Severity High distro-darwin type-library labels Oct 19, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

unwanted warning from diagnostics.pm under -w #11233

unwanted warning from diagnostics.pm under -w #11233

p5pRT commented Apr 4, 2011

p5pRT commented Apr 4, 2011

p5pRT commented Apr 4, 2011

p5pRT commented Apr 4, 2011

p5pRT commented Apr 4, 2011

p5pRT commented Apr 4, 2011

p5pRT commented Apr 4, 2011

p5pRT commented Apr 4, 2011

p5pRT commented Apr 5, 2011

p5pRT commented Apr 5, 2011

p5pRT commented Apr 6, 2011

p5pRT commented Apr 6, 2011

unwanted warning from diagnostics.pm under -w #11233

unwanted warning from diagnostics.pm under -w #11233

Comments

p5pRT commented Apr 4, 2011

p5pRT commented Apr 4, 2011

From @cpansprout

p5pRT commented Apr 4, 2011

From @obra

p5pRT commented Apr 4, 2011

p5pRT commented Apr 4, 2011

From @cpansprout

p5pRT commented Apr 4, 2011

From [Unknown Contact. See original ticket]

p5pRT commented Apr 4, 2011

From @khwilliamson

p5pRT commented Apr 4, 2011

From @tamias

p5pRT commented Apr 5, 2011

From @khwilliamson

p5pRT commented Apr 5, 2011

From @obra

p5pRT commented Apr 6, 2011

From @obra

p5pRT commented Apr 6, 2011