Mailing List Archive: Perl: porters

[perl #114504] $ENV{foo}=undef

Index | Next | Previous | View Threaded

perlbug-followup at perl

Aug 19, 2012, 12:20 PM

Post #1 of 8 (114 views)
Permalink

[perl #114504] $ENV{foo}=undef

# New Ticket Created by Father Chrysostomos
# Please include the string: [perl #114504]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=114504 >

perldelta for 5.17.3 has this under Incompatible Changes:

=head2 C<$ENV{foo}=undef> deletes value from environ, like C<delete $ENV{foo}>

This facilitates use of C<local()> with C<%ENV> entries. In previous versions
of Perl, C<undef> was converted to the empty string.

I donā€™t recall seeing this discussed. This change makes Perl less consistent with itself. For undef to be converted to the empty string is normal. For $hash{key} = undef to delete the hash element is abnormal. And I donā€™t see what it provides, except inconsistency. We already have delete local.

I think this should be reverted.

---
Flags:
category=core
severity=low
---
Site configuration information for perl 5.17.3:

Configured by sprout at Mon Jul 30 23:46:13 PDT 2012.

Summary of my perl5 (revision 5 version 17 subversion 3) configuration:
Snapshot of: 7e2a0d4586762cf28c9cdfb3c49d57d805879ac9
Platform:
osname=darwin, osvers=10.5.0, archname=darwin-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='-de -Dusedevel -DDEBUGGING=-g'
hint=recommended, useposix=true, d_sigaction=define
useithreads=undef, usemultiplicity=undef
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 -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include',
optimize='-O3 -g',
cppflags='-fno-common -DPERL_DARWIN -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=, 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.17.3:
/usr/local/lib/perl5/site_perl/5.17.3/darwin-2level
/usr/local/lib/perl5/site_perl/5.17.3
/usr/local/lib/perl5/5.17.3/darwin-2level
/usr/local/lib/perl5/5.17.3
/usr/local/lib/perl5/site_perl
.

---
Environment for perl 5.17.3:
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

doy at tozt

Aug 20, 2012, 2:19 AM

Post #2 of 8 (98 views)
Permalink

Re: [perl #114504] $ENV{foo}=undef [In reply to]

On Sun, Aug 19, 2012 at 12:20:21PM -0700, Father Chrysostomos wrote:
> perldelta for 5.17.3 has this under Incompatible Changes:
>
> =head2 C<$ENV{foo}=undef> deletes value from environ, like C<delete $ENV{foo}>
>
> This facilitates use of C<local()> with C<%ENV> entries. In previous versions
> of Perl, C<undef> was converted to the empty string.
>
>
> I donā€™t recall seeing this discussed. This change makes Perl less consistent with itself. For undef to be converted to the empty string is normal. For $hash{key} = undef to delete the hash element is abnormal. And I donā€™t see what it provides, except inconsistency. We already have delete local.
>
> I think this should be reverted.

+1

-doy

Eirik-Berg.Hanssen at allverden

Aug 20, 2012, 3:16 AM

Post #3 of 8 (101 views)
Permalink

Re: [perl #114504] $ENV{foo}=undef [In reply to]

On Mon, Aug 20, 2012 at 11:19 AM, Jesse Luehrs <doy [at] tozt> wrote:

> On Sun, Aug 19, 2012 at 12:20:21PM -0700, Father Chrysostomos wrote:
> > perldelta for 5.17.3 has this under Incompatible Changes:
> >
> > =head2 C<$ENV{foo}=undef> deletes value from environ, like C<delete
> $ENV{foo}>
> >
> > This facilitates use of C<local()> with C<%ENV> entries. In previous
> versions
> > of Perl, C<undef> was converted to the empty string.
> >
> >
> > I don’t recall seeing this discussed. This change makes Perl less
> consistent with itself. For undef to be converted to the empty string is
> normal. For $hash{key} = undef to delete the hash element is abnormal.
> And I don’t see what it provides, except inconsistency. We already have
> delete local.
> >
> > I think this should be reverted.
>
> +1
>

Briefly discussed, July 25th.

Questioned:
http://www.nntp.perl.org/group/perl.perl5.porters/2012/07/msg189929.html

Answered:
http://www.nntp.perl.org/group/perl.perl5.porters/2012/07/msg189942.html

But yeah, the answer seems a bit too brief. As you note, C<< delete
local >> does the job, and if only string values are accepted, I'd expect
assignment of undef to yield the empty string.

As it is part of a bigger change, I wouldn't ask for it all to be
reverted, but this corner of the peanut gallery would also prefer the old
behaviour of assignment of undefined values. Is it doable?

Eirik

perlbug-comment at perl

Aug 20, 2012, 8:26 AM

Post #4 of 8 (100 views)
Permalink

[perl #114504] $ENV{foo}=undef [In reply to]

On Mon Aug 20 03:16:41 2012, Eirik-Berg.Hanssen [at] allverden wrote:
> On Mon, Aug 20, 2012 at 11:19 AM, Jesse Luehrs <doy [at] tozt> wrote:
>
> > On Sun, Aug 19, 2012 at 12:20:21PM -0700, Father Chrysostomos wrote:
> > > perldelta for 5.17.3 has this under Incompatible Changes:
> > >
> > > =head2 C<$ENV{foo}=undef> deletes value from environ, like C<delete
> > $ENV{foo}>
> > >
> > > This facilitates use of C<local()> with C<%ENV> entries. In previous
> > versions
> > > of Perl, C<undef> was converted to the empty string.
> > >
> > >
> > > I donā€™t recall seeing this discussed. This change makes Perl less
> > consistent with itself. For undef to be converted to the empty
string is
> > normal. For $hash{key} = undef to delete the hash element is abnormal.
> > And I donā€™t see what it provides, except inconsistency. We already
have
> > delete local.
> > >
> > > I think this should be reverted.
> >
> > +1
> >
>
> Briefly discussed, July 25th.
>
> Questioned:
> http://www.nntp.perl.org/group/perl.perl5.porters/2012/07/msg189929.html
>
> Answered:
> http://www.nntp.perl.org/group/perl.perl5.porters/2012/07/msg189942.html
>
> But yeah, the answer seems a bit too brief.

I do recall that now, but I did not understand it at the time. I
assumed it had something to do with local $ENV{foo} = $ENV{foo}, which
used to be buggy until Chip fixed it a few years ago. (local $^W = $^W;
still exhibits the bug.)

> As you note, C<< delete
> local >> does the job, and if only string values are accepted, I'd expect
> assignment of undef to yield the empty string.
>
> As it is part of a bigger change, I wouldn't ask for it all to be
> reverted, but this corner of the peanut gallery would also prefer the old
> behaviour of assignment of undefined values. Is it doable?

Anythingā€™s doable. :-) Itā€™s probably simple, too.

--

Father Chrysostomos

perl.p5p at rjbs

Aug 24, 2012, 6:19 PM

Post #5 of 8 (96 views)
Permalink

Re: [perl #114504] $ENV{foo}=undef [In reply to]

* Father Chrysostomos via RT <perlbug-comment [at] perl> [2012-08-20T11:26:08]
> I do recall that now, but I did not understand it at the time. I
> assumed it had something to do with local $ENV{foo} = $ENV{foo}, which
> used to be buggy until Chip fixed it a few years ago. (local $^W = $^W;
> still exhibits the bug.)

I also thought so.

I wonder whether Chip was not aware that "delete local" had been made to work;
that's a newer-than-5.8 change and I think it was often overlooked. (But not
by me, as I asked for it and was delighted to see it get implemented!)

Chip, can you weigh in on this?

--
rjbs

Attachments:

signature.asc (0.48 KB)

xsawyerx at gmail

Oct 15, 2012, 3:03 PM

Post #6 of 8 (46 views)
Permalink

Re: [perl #114504] $ENV{foo}=undef [In reply to]

On 10/13/2012 04:03 PM, Father Chrysostomos via RT wrote:
> On Fri Aug 24 18:20:10 2012, perl.p5p [at] rjbs wrote:
>> * Father Chrysostomos via RT <perlbug-comment [at] perl> [2012-08-
>> 20T11:26:08]
>>> I do recall that now, but I did not understand it at the time. I
>>> assumed it had something to do with local $ENV{foo} = $ENV{foo},
>> which
>>> used to be buggy until Chip fixed it a few years ago. (local $^W =
>> $^W;
>>> still exhibits the bug.)
>> I also thought so.
> It turns out that perldelta entry that inspired this ticket is wrong.
> With current bleadperl I get this:
>
> $ ./perl -Ilib -le '$ENV{PATH} = undef; print exists $ENV{PATH}; local
> $ENV{PATH}; print exists $ENV{PATH}'
> 1
> 1
>
> Nothing more to do here, as far as Iā€™m concerned.
Wasn't this also related to the CPANPLUS discussion and failing on VMS?

rev.chip at gmail

Oct 16, 2012, 9:44 AM

Post #7 of 8 (46 views)
Permalink

Re: [perl #114504] $ENV{foo}=undef [In reply to]

On Fri, Aug 24, 2012 at 09:19:40PM -0400, Ricardo Signes wrote:
> * Father Chrysostomos via RT <perlbug-comment [at] perl> [2012-08-20T11:26:08]
> > I do recall that now, but I did not understand it at the time. I
> > assumed it had something to do with local $ENV{foo} = $ENV{foo}, which
> > used to be buggy until Chip fixed it a few years ago. (local $^W = $^W;
> > still exhibits the bug.)
>
> I also thought so.
>
> I wonder whether Chip was not aware that "delete local" had been made to work...
> [...]
> Chip, can you weigh in on this?

Indeed I wasn't aware. The below code works (no die) on 5.14:

# Test that $ENV{X} = undef does *not* need a special case
$ENV{X} = 'x';
{
delete local $ENV{X};
die "Unhappy 1" if `env` =~ /^X=/m;
}
die "Unhappy 2" unless `env` =~ /^X=/m;

So special case of C<$ENV{X}=undef> performing unsetenv is a mistake and
should be removed.
--
Chip Salzenberg

craig.a.berry at gmail

Feb 23, 2013, 9:55 AM

Post #8 of 8 (18 views)
Permalink

Re: [perl #114504] $ENV{foo}=undef [In reply to]

On Sat, Feb 16, 2013 at 12:46 PM, Kent Fredric via RT
<perlbug-comment [at] perl> wrote:
> Just regenerated the patch with a cleanup of the ENV variable I added for
> my test. I didn't see that the first time around. VMS is *weird*

If you're referring to the snippets of eccentricity in mg.c and hv.c,
that's only the tip of the iceberg; the darker magic is in vms/vms.c.

I'm actually not sure what to do about this change on VMS.
t/op/magic.t now fails like so:

ok 157 - setting $0 does not break %ENV
not ok 158 - setting a key as undef does not delete it
# Failed test 158 - setting a key as undef does not delete it at
op/magic.t line 69
# got "\000\n"
# expected "\n"
ok 159 - ENV store of stringified glob

What's happening here is that when we set an environment variable to
undef, we're actually storing a null byte as the value in the "real"
(external to Perl) environment. This is necessary because storing
zero-length values is not allowed. It's possible because the native
interfaces do not use C (ASCIZ) strings but always specify string
lengths on input and output.

When we retrieve such a value from Perl, we correctly recognize that
the value exists but is undefined:

$ perl -e "$ENV{XYZ}='foo'; $ENV{XYZ}=undef; print qq/exists but
undef\n/ if exists $ENV{XYZ} && !defined $ENV{XYZ};"
exists but undef

but the env_is() subroutine in magic.t is retrieving that null byte by
running an external command. I guess I will just hack up env_is() to
handle this special case.

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads