BBC: Blead Breaks Excel::Writer::XLSX

[cjg-cguevara]

This is a bug report for perl from "Carlos Guevara" carlos@carlosguevara.com, generated with the help of perlbug 1.42 running under perl 5.35.10.

---

[Please describe your issue here]

BBC: Blead Breaks Excel::Writer::XLSX

Please see http://matrix.cpantesters.org/?dist=Excel::Writer::XLSX

[Please do not change anything below this line]

---

Flags: category=core severity=low

Site configuration information for perl 5.35.10:

Configured by cpan at Tue Mar 8 09:26:05 EST 2022.

Summary of my perl5 (revision 5 version 35 subversion 10) configuration: Commit id: f70b3f77e0c82e8e1b599de1542ef342631cb4f5 Platform: osname=openbsd osvers=7.0 archname=OpenBSD.amd64-openbsd uname='openbsd cjg-openbsd7 7.0 generic#5 amd64 ' config_args='-des -Dprefix=~/bin/perl-blead -Dscriptdir=~/bin/perl-blead/bin -Dusedevel -Duse64bitall' hint=recommended useposix=true d_sigaction=define useithreads=undef usemultiplicity=undef use64bitint=define use64bitall=define uselongdouble=undef usemymalloc=n default_inc_excludes_dot=define Compiler: cc='cc' ccflags ='-fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include' optimize='-O2' cppflags='-fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include' ccversion='' gccversion='OpenBSD Clang 11.1.0' gccosandvers='' intsize=4 longsize=8 ptrsize=8 doublesize=8 byteorder=12345678 doublekind=3 d_longlong=define longlongsize=8 d_longdbl=define longdblsize=16 longdblkind=3 ivtype='long' ivsize=8 nvtype='double' nvsize=8 Off_t='off_t' lseeksize=8 alignbytes=8 prototype=define Linker and Libraries: ld='cc' ldflags ='-Wl,-E -fstack-protector-strong -L/usr/local/lib' libpth=/usr/lib /usr/local/lib libs=-lpthread -lm -lutil -lc perllibs=-lpthread -lm -lutil -lc libc=/usr/lib/libc.so.96.1 so=so useshrplib=false libperl=libperl.a gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs dlext=so d_dlsymun=undef ccdlflags=' ' cccdlflags='-DPIC -fPIC ' lddlflags='-shared -fPIC -L/usr/local/lib -fstack-protector-strong'

---

@INC for perl 5.35.10: /home/cpan/bin/perl-blead/lib/site_perl/5.35.10/OpenBSD.amd64-openbsd /home/cpan/bin/perl-blead/lib/site_perl/5.35.10 /home/cpan/bin/perl-blead/lib/5.35.10/OpenBSD.amd64-openbsd /home/cpan/bin/perl-blead/lib/5.35.10

---

Environment for perl 5.35.10: HOME=/home/cpan LANG (unset) LANGUAGE (unset) LC_ALL=C LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=/home/cpan/bin/perl-blead/bin:/home/cpan/bin:/home/cpan/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin:/usr/games PERL_BADLANG (unset) SHELL=/usr/local/bin/bash

[haarg]

Pretty sure this is caused by 8b03aeb95ab72abdb2fa40f2d1196ce42f34708d. The test is opening a reference to an undef scalar variable, writing nothing to it, and expecting the variable to still be undef.

I could see the argument that reading from an undef filehandle should emit a single warning, and writing to it should autovivify it to an empty string, but I haven't thought about it too extensively.

Ping @demerphq

[demerphq]

On Fri, 11 Mar 2022 at 11:57, Graham Knop @.***> wrote:

Pretty sure this is caused by 8b03aeb https://github.com/Perl/perl5/commit/8b03aeb95ab72abdb2fa40f2d1196ce42f34708d. The test is opening a reference to an undef scalar variable, writing nothing to it, and expecting the variable to still be undef.

I could see the argument that reading from an undef filehandle should emit a single warning, and writing to it should autovivify it to an empty string, but I haven't thought about it too extensively.

I feel pretty strongly that this is just like autovivification. If you have code like:

my $x; if ($x->{foo}) { ... }

$x won't be undef afterwards, it will be a hashref.

If somebody opens a scalar for read and it is undef, it should autovivify into a string.

I feel like it would be better to just push patches to the affected modules to test for falseness not undefinedness.

cheers, Yves

[demerphq]

On Fri, 11 Mar 2022 at 12:12, demerphq @.***> wrote:

On Fri, 11 Mar 2022 at 11:57, Graham Knop @.***> wrote:

Pretty sure this is caused by 8b03aeb. The test is opening a reference to an undef scalar variable, writing nothing to it, and expecting the variable to still be undef.

I could see the argument that reading from an undef filehandle should emit a single warning, and writing to it should autovivify it to an empty string, but I haven't thought about it too extensively.

I feel pretty strongly that this is just like autovivification. If you have code like:

my $x; if ($x->{foo}) { ... }

$x won't be undef afterwards, it will be a hashref.

If somebody opens a scalar for read and it is undef, it should autovivify into a string.

I feel like it would be better to just push patches to the affected modules to test for falseness not undefinedness.

Anyway, I dont think this is high priority, ill push a revert branch and we can pick it up again in 5.37

Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"

[khwilliamson]

Can we confirm that this has been fixed by the reversion of the patch?

[jmcnamara]

@khwilliamson I can confirm. It works locally for me (the developer of Excel::Writer::XLSX) and the failing CPAN testing reports have stopped.

[demerphq]

Should we retry this in 5.37?

[jkeenan]

@khwilliamson I can confirm. It works locally for me (the developer of Excel::Writer::XLSX) and the failing CPAN testing reports have stopped.

Currently Excel::Writer::XLSX is doing fine on CPANtesters. But, IIUC, that's because we reverted a patch -- correct? If we're going to "revert the revert," I recommend starting a fresh ticket for the change we want to make.