Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dangerous behavior from local #850

Closed
p5pRT opened this issue Nov 14, 1999 · 14 comments
Closed

dangerous behavior from local #850

p5pRT opened this issue Nov 14, 1999 · 14 comments

Comments

@p5pRT
Copy link
Collaborator

@p5pRT p5pRT commented Nov 14, 1999

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

Searchable as RT1778$

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Nov 14, 1999

From pimlott@idiomtech.com

A coworker accidentally did​:

{
  local($/ = undef);
  ...
}

This did not localize $/ . I don't know what it did do. There was no
warning. Could I get a warning out of it?

Thanks,
Andrew

Perl Info


Site configuration information for perl 5.00503:

Configured by torin at Wed Sep 22 00:18:38 PDT 1999.

Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration:
  Platform:
    osname=linux, osvers=2.0.36, archname=i386-linux
    uname='linux perv 2.0.36 #2 wed nov 18 03:00:48 pst 1998 i686 unknown '
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=undef useperlio=undef d_sfio=undef
  Compiler:
    cc='cc', optimize='-O2', gccversion=2.95.1 19990809 (prerelease)
    cppflags='-Dbool=char -DHAS_BOOL -D_REENTRANT -DDEBIAN -I/usr/local/include'
    ccflags ='-Dbool=char -DHAS_BOOL -D_REENTRANT -DDEBIAN -I/usr/local/include'
    stdchar='char', d_stdstdio=undef, usevfork=false
    intsize=4, longsize=4, ptrsize=4, doublesize=8
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    alignbytes=4, usemymalloc=n, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib
    libs=-lnsl -lndbm -lgdbm -ldbm -ldb -ldl -lm -lc -lposix -lcrypt
    libc=, so=so, useshrplib=false, libperl=libperl.a
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
    cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib'

Locally applied patches:
    


@INC for perl 5.00503:
    /home/pimlott/idiom/perl
    /usr/lib/perl5/5.005/i386-linux
    /usr/lib/perl5/5.005
    /usr/local/lib/site_perl/i386-linux
    /usr/local/lib/site_perl
    /usr/lib/perl5
    .


Environment for perl 5.00503:
    HOME=/home/pimlott
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/home/pimlott/bin:/usr/sbin:/sbin:/home/pimlott/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games
    PERL5LIB=/home/pimlott/idiom/perl
    PERL_BADLANG (unset)
    SHELL=/usr/bin/zsh

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Nov 15, 1999

From [Unknown Contact. See original ticket]

On Sun, 14 Nov 1999, Andrew Pimlott wrote​:

A coworker accidentally did​:

{
local($/ = undef);
...
}

This did not localize $/ . I don't know what it did do.

It looks to me as if it did localize $/ -- but only _after_ storing undef
into it. Oops!

There was no warning. Could I get a warning out of it?

Or, better yet, could perl simply Do The Right Thing?

--
Tom Phoenix Perl Training and Hacking Esperanto
Randal Schwartz Case​: http​://www.rahul.net/jeffrey/ovs/

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Nov 15, 1999

From @tamias

On Mon, Nov 15, 1999 at 07​:01​:44PM -0800, Tom Phoenix wrote​:

On Sun, 14 Nov 1999, Andrew Pimlott wrote​:

A coworker accidentally did​:

{
local($/ = undef);
...
}

This did not localize $/ . I don't know what it did do.

It looks to me as if it did localize $/ -- but only _after_ storing undef
into it. Oops!

That was my guess, too, but further tests don't seem to be consistent with
that conclusion​:

#!perl -w

$x = 'a';

print "1​: $x\n";

{
  local($x = undef);
  print "2​: $x\n";
  $x = 'b';
  print "3​: $x\n";
}

print "4​: $x\n";


1​: a
Use of uninitialized value at foo line 9.
2​:
3​: b
4​: b

--

If $x were being localized at all, then 4 would be 'a', rather than 'b'.

Ronald

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Nov 15, 1999

From [Unknown Contact. See original ticket]

On Mon, Nov 15, 1999 at 07​:01​:44PM -0800, Tom Phoenix wrote​:

On Sun, 14 Nov 1999, Andrew Pimlott wrote​:

A coworker accidentally did​:

{
local($/ = undef);
...
}

This did not localize $/ . I don't know what it did do.

It looks to me as if it did localize $/ -- but only _after_ storing undef
into it. Oops!

That made so much sense when someone else pointed it out, I felt like an
idiot. Tragically, it is not so. Try this​:

#!/usr/bin/perl -w

{
  local($/ = undef);
  $/ = "0";
}
print scalar <>;
__END__

You will find that the input separator is "0". $/ is never localized.
Beats me what is.

Andrew

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Nov 16, 1999

From [Unknown Contact. See original ticket]

Tom Phoenix <rootbeer@​redcat.com> writes​:

On Sun, 14 Nov 1999, Andrew Pimlott wrote​:

A coworker accidentally did​:

{
local($/ = undef);
...
}

This did not localize $/ . I don't know what it did do.

It looks to me as if it did localize $/ -- but only _after_ storing undef
into it. Oops!

That is exactly what it says ;-)

There was no warning. Could I get a warning out of it?

Or, better yet, could perl simply Do The Right Thing?

I think it is doing the right thing.

--
Nick Ing-Simmons <nik@​tiuk.ti.com>
Via, but not speaking for​: Texas Instruments Ltd.

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Nov 16, 1999

From [Unknown Contact. See original ticket]

From​: Ronald J Kimball [mailto​:rjk@​linguist.dartmouth.edu]

It looks to me as if it did localize $/ -- but only _after_
storing undef into it. Oops!

That was my guess, too, but further tests don't seem to be
consistent with that conclusion​:

Could it be that Perl is
  1. Storing undef into $/
  2. Looking at the local()
  3. "Realising" that, as $/ is undefined, it is a new variable
  and so localising is "unnecessary", therefore not doing it.

Ie, could it be an optimiser bug?

Paul.

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Nov 16, 1999

From [Unknown Contact. See original ticket]

"Moore, Paul" <Paul.Moore@​uk.origin-it.com> wrote

3. "Realising" that, as $/ is undefined, it is a new variable
and so localising is "unnecessary", therefore not doing it.

Ie, could it be an optimiser bug?

It certainly would be a bug if the optimiser did that. But experiment
shows that it doesn't confuse the concepts "undefined" and "uninitialised"​:

% perl -w
$x = 13;
{ undef $x;
  local $x = undef;
  $x = 12;
};
print $x;
__END__
Use of uninitialized value at - line 6.

Mike Guy

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Nov 16, 1999

From [Unknown Contact. See original ticket]

Nick Ing-Simmons <nik@​tiuk.ti.com> wrote

I think it is doing the right thing.

It has been pointed out that the construct apparently isn't localising
anything.

It can't be right for a local() not to localise anything *and* give
no warning.

And as another data point, I note that

  local (undef);

is valid Perl. I suspect that '$/ = undef' is being evaluated as
'undef' and passed as argument to local().

Mike Guy

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Nov 16, 1999

From [Unknown Contact. See original ticket]

Watch this​:

  Top x= 0 y=stone &x=080da578 &y=080da59c
  Inside Before x=10 y=fred &x=080d3f8c &y=080d3e9c
  Inside x=20 y=barney &x=080da548 &y=080d3e9c
  Outside x=10 y=barney &x=080d3f8c &y=080d3e9c
  Way Outside x= 0 y=stone &x=080da578 &y=080da59c

That's produced by the attached program. Notice that the
address of y is not altered inside, whereas that of x is.

--tom

$x = '0';
$y = "stone";

sub show {
  printf "%-20s x=%2d y=%-6s &x=%08x &y=%08x\n",
  shift, $x, $y, \$x, \$y;
}

show("Top");

{
  local $x = 10;
  local $y = "fred";

  show("Inside Before");

  {
  local $x = 20;
  local($y = "barney");
  show("Inside");
  }
  show("Outside");
}

show("Way Outside");

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 13, 2000

From [Unknown Contact. See original ticket]

This bug appears to still be active. There is some discussion as to
whether it is a bug or not.

A coworker accidentally did​:

{
  local($/ = undef);
  ...
}

This did not localize $/ . I don't know what it did do. There was no
warning. Could I get a warning out of it?

-spp

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Mar 6, 2001

From [Unknown Contact. See original ticket]

Another reminder that this bug is still active​:

Watch this​:

  Top x= 0 y=stone &x=080da578 &y=080da59c
  Inside Before x=10 y=fred &x=080d3f8c &y=080d3e9c
  Inside x=20 y=barney &x=080da548 &y=080d3e9c
  Outside x=10 y=barney &x=080d3f8c &y=080d3e9c
  Way Outside x= 0 y=stone &x=080da578 &y=080da59c

That's produced by the attached program. Notice that the
address of y is not altered inside, whereas that of x is.

--tom

$x = '0';
$y = "stone";

sub show {
  printf "%-20s x=%2d y=%-6s &x=%08x &y=%08x\n",
  shift, $x, $y, \$x, \$y;
}

show("Top");

{
  local $x = 10;
  local $y = "fred";

  show("Inside Before");

  {
  local $x = 20;
  local($y = "barney");
  show("Inside");
  }
  show("Outside");
}

show("Way Outside");

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Aug 7, 2002

From @gbarr

This is still present in 5.8.0

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented May 26, 2003

From @iabyn

(Just reviewing old Perl bug reports).

In the latest development versions of Perl (which will eventually
be released as 5.8.1 and 5.10.0), the code now gives a warning​:

$ ./perl -we 'local($/ = undef)'
Useless localization of scalar assignment at -e line 1.
$

This was added by patch #19588

Regards,

Dave M.

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented May 26, 2003

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant
You can’t perform that action at this time.