Subject: | P:C failure for File::Slurp with bleedperl hard to understand |
When I test File::Slurp 9999.12 with bleedperl, I see a failing
t/pod_coverage.t complaining about
# FD_CLOEXEC
# F_DUPFD
# F_GETFD
# F_GETFL
# F_GETLK
# F_RDLCK
# F_SETFD
# F_SETFL
# F_SETLK
# F_SETLKW
# F_UNLCK
# F_WRLCK
# O_ACCMODE
# O_NOCTTY
# O_NONBLOCK
# O_RDWR
# O_TRUNC
With perl-5.8.8 the test succeeds.
Stepping through the debugger I find this Pod::Coverage object:
DB<3> x $pc
0 Pod::Coverage=HASH(0x8696e40)
'nonwhitespace' => undef
'package' => 'File::Slurp'
'pod_from' =>
'/home/k/.cpan/build/File-Slurp-9999.12/blib/lib/File/Slurp.pm'
'private' => ARRAY(0x8841fcc)
0 (?-xism:^_)
-> qr/(?-xism:^_)/
1 (?-xism:^import$)
-> qr/(?-xism:^import$)/
2 (?-xism:^DESTROY$)
-> qr/(?-xism:^DESTROY$)/
3 (?-xism:^AUTOLOAD$)
-> qr/(?-xism:^AUTOLOAD$)/
4 (?-xism:^bootstrap$)
-> qr/(?-xism:^bootstrap$)/
5 (?-xism:^\\()
-> qr/(?-xism:^\()/
6 (?x-ism:^(TIE( SCALAR | ARRAY | HASH | HANDLE ) |
FETCH | STORE | UNTIE | FETCHSIZE | STORESIZE |
POP | PUSH | SHIFT | UNSHIFT | SPLICE | DELETE |
EXISTS | EXTEND | CLEAR | FIRSTKEY | NEXTKEY | PRINT | PRINTF |
WRITE | READLINE | GETC | READ | CLOSE | BINMODE | OPEN |
EOF | FILENO | SEEK | TELL)$)
-> qr/(?x-ism:^(TIE( SCALAR | ARRAY | HASH | HANDLE ) |
FETCH | STORE | UNTIE | FETCHSIZE | STORESIZE |
POP | PUSH | SHIFT | UNSHIFT | SPLICE | DELETE |
EXISTS | EXTEND | CLEAR | FIRSTKEY | NEXTKEY | PRINT | PRINTF |
WRITE | READLINE | GETC | READ | CLOSE | BINMODE | OPEN |
EOF | FILENO | SEEK | TELL)$)/
7 (?x-ism:^( MODIFY | FETCH )_( REF | SCALAR | ARRAY | HASH | CODE |
GLOB | FORMAT | IO)_ATTRIBUTES $)
-> qr/(?x-ism:^( MODIFY | FETCH )_( REF | SCALAR | ARRAY | HASH
| CODE |
GLOB | FORMAT | IO)_ATTRIBUTES $)/
8 (?-xism:^CLONE(_SKIP)?$)
-> qr/(?-xism:^CLONE(_SKIP)?$)/
'symbols' => HASH(0x879b3f8)
'FD_CLOEXEC' => 0
'F_DUPFD' => 0
'F_GETFD' => 0
'F_GETFL' => 0
'F_GETLK' => 0
'F_RDLCK' => 0
'F_SETFD' => 0
'F_SETFL' => 0
'F_SETLK' => 0
'F_SETLKW' => 0
'F_UNLCK' => 0
'F_WRLCK' => 0
'O_ACCMODE' => 0
'O_APPEND' => 1
'O_BINARY' => 1
'O_CREAT' => 1
'O_EXCL' => 1
'O_NOCTTY' => 0
'O_NONBLOCK' => 0
'O_RDONLY' => 1
'O_RDWR' => 0
'O_TRUNC' => 0
'O_WRONLY' => 1
'SEEK_CUR' => 1
'SEEK_END' => 1
'SEEK_SET' => 1
'append_file' => 1
'overwrite_file' => 1
'read_dir' => 1
'read_file' => 1
'slurp' => 1
'write_file' => 1
'trustme' => ARRAY(0x863142c)
0 'slurp'
1 'O_APPEND'
2 'O_BINARY'
3 'O_CREAT'
4 'O_EXCL'
5 'O_RDONLY'
6 'O_WRONLY'
7 'SEEK_CUR'
8 'SEEK_END'
9 'SEEK_SET'
I have put a patch for File::Slurp on CPAN:
ANDK/patches/File-Slurp-9999.12-ANDK-02.patch
that defends against this bug but I would feel better if I knew what the
real reason and fix is.