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

search position reset after 'local' save/restore #789

Closed
p5pRT opened this issue Oct 26, 1999 · 16 comments
Closed

search position reset after 'local' save/restore #789

p5pRT opened this issue Oct 26, 1999 · 16 comments

Comments

@p5pRT
Copy link
Collaborator

@p5pRT p5pRT commented Oct 26, 1999

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

Searchable as RT1716$

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Oct 26, 1999

From oloryn@mindspring.com

jalex mentioned this on #perl. I'm not sure if he sent in a bug report
or not.

This program​:

#!/usr/bin/perl -w
$x = "123 56"; $x =~ / /g;
print "$x, ", pos($x), "\n";
{ local $x }
print "$x, ", pos($x), "\n";

produces the output

123 56, 4
123 56, Use of uninitialized value at test.plx line 5.

The search position for a match appears to be reset when the target
variable goes through a 'local' save and restore.

I get the same results on 5.005_03 on linux.

Ben


Site configuration information for perl 5.00553​:

Configured by bcoleman at Sat Feb 13 21​:36​:29 EST 1999.

Summary of my perl5 (5.0 patchlevel 5 subversion 53) configuration​:
  Platform​:
  osname=os2, osvers=2.40, archname=os2
  uname='os2 oloryn 2 2.40 i386 '
  hint=recommended, useposix=true, d_sigaction=define
  usethreads=undef useperlio=undef d_sfio=undef
  Compiler​:
  cc='gcc', optimize='-O2 -fomit-frame-pointer -malign-loops=2 -malign-jumps=2 -malign-functions=2 -s', gccversion=2.7.2.1
  cppflags='-Zomf -Zmt -DDOSISH -DOS2=2 -DEMBED -I.'
  ccflags ='-Zomf -Zmt -DDOSISH -DOS2=2 -DEMBED -I.'
  stdchar='char', d_stdstdio=define, usevfork=false
  intsize=4, longsize=4, ptrsize=4, doublesize=8
  d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
  alignbytes=4, usemymalloc=y, prototype=define
  Linker and Libraries​:
  ld='gcc', ldflags ='-Zexe -Zomf -Zmt -Zcrtdll -Zstack 32000'
  libpth=g​:/emx/lib G​:/JAVA11/LIB g​:/emx/lib/mt
  libs=-lsocket -lm -lbsd
  libc=g​:/emx/lib/mt/c_import.lib, so=dll, useshrplib=true, libperl=libperl.lib
  Dynamic Linking​:
  dlsrc=dl_dlopen.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
  cccdlflags='-Zdll', lddlflags='-Zdll -Zomf -Zmt -Zcrtdll -s'

Locally applied patches​:
 


@​INC for perl 5.00553​:
  g​:/perl/lib/5.00553/os2
  g​:/perl/lib/5.00553
  g​:/perl/lib/site_perl/5.00553/os2
  g​:/perl/lib/site_perl/5.00553
  .


Environment for perl 5.00553​:
  HOME=F​:\home\
  LANG=EN_US
  LD_LIBRARY_PATH (unset)
  LOGDIR (unset)
  PATH=F​:\NETSCAPE\PROGRAM;H​:\MPTN\BIN;H​:\IBMCOM;G​:\GNU\BIN;H​:\OS2;H​:\OS2\SYSTEM;H​:\OS2\MDOS\WINOS2;H​:\OS2\INSTALL;H​:\;H​:\OS2\MDOS;H​:\OS2\APPS;H​:\MMOS2;G​:\EMX\BIN;F​:\OS2BIN;F​:\OS2BIN\PERL;G​:\EPM;G​:\TS\OS2_SYS;F​:\PGP26;F​:\BACKMAST;F​:\INCHARGE;F​:\BONUSPAK\IBMWORKS;H​:\TCPIP\BIN;H​:\TCPIP\PCOMOS2;H​:\TCPIP\UMAIL;G​:\PERL\BIN;G​:\PERL\OS2BIN;F​:\BA2PRO;F​:\PERF_30;F​:\PERF_30;G​:\XFree86\bin;F​:\Office50;H​:\JAVA11\BIN;F​:\emtex\bin;F​:\gstools\gs5.50;
  PERL_BADLANG=0
  PERL_BADLANG=0
  PERL_SH_DIR=G​:\GNU\BIN
  SHELL (unset)

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 14, 2000

From [Unknown Contact. See original ticket]

Still true as of @​8079.

This is a bug report for perl from oloryn@​mindspring.com,
generated with the help of perlbug 1.26 running under perl 5.00553.

jalex mentioned this on #perl. I'm not sure if he sent in a bug report
or not.

This program​:

#!/usr/bin/perl -w
$x = "123 56"; $x =~ / /g;
print "$x, ", pos($x), "\n";
{ local $x }
print "$x, ", pos($x), "\n";

produces the output

123 56, 4
123 56, Use of uninitialized value at test.plx line 5.

The search position for a match appears to be reset when the target
variable goes through a 'local' save and restore.

I get the same results on 5.005_03 on linux.

Ben

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Feb 19, 2002

From The RT System itself

123 56, 4
Use of uninitialized value in print at - line 5.
123 56,

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Feb 19, 2002

From The RT System itself

$x = "123 56"; $x =~ / /g;
print "$x, ", pos($x), "\n";
{ local $x }
print "$x, ", pos($x), "\n";

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Aug 7, 2002

From @gbarr

This is still true in 5.8.0

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Sep 9, 2002

From josh@greentechnologist.org

Created by jjore@imation.com

The mg_len attribute is set to -1 after local() is applied
to a PVMG with 'g' magic. This is how pos() works so really local()
breaks pos(). I reproduced the problem on cygwin perl 5.8.0 and
OpenBSD 3.1 perl 5.6.1.

This code fragment demonstrates the problem​:

use Devel​::Peek;
$a = 'a';
$a =~ m/./g;
Dump($a); # mg_len = 1
  # 1 = pos($a)
{
  local $a = 'b';
  Dump($a); # mg_len = -1
  # undef = pos($a)
};
Dump($a); # mg_len = -1
  # undef = pos($a)

Perl Info

Flags:
    category=core
    severity=medium

Site configuration information for perl v5.6.1:

Configured by ActiveState at Mon Jun 17 21:32:50 2002.

Summary of my perl5 (revision 5 version 6 subversion 1) configuration:
  Platform:
    osname=MSWin32, osvers=4.0, archname=MSWin32-x86-multi-thread
    uname=''
    config_args='undef'
    hint=recommended, useposix=true, d_sigaction=undef
    usethreads=undef use5005threads=undef useithreads=define usemultiplicity=define
    useperlio=undef d_sfio=undef uselargefiles=undef usesocks=undef
    use64bitint=undef use64bitall=undef uselongdouble=undef
  Compiler:
    cc='cl', ccflags ='-nologo -O1 -MD -DNDEBUG -DWIN32 -D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT  -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DPERL_MSVCRT_READFIX',
    optimize='-O1 -MD -DNDEBUG',
    cppflags='-DWIN32'
    ccversion='', gccversion='', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
    d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=10
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=4
    alignbytes=8, usemymalloc=n, prototype=define
  Linker and Libraries:
    ld='link', ldflags ='-nologo -nodefaultlib -release  -libpath:"C:/Perl\lib\CORE"  -machine:x86'
    libpth="C:\VCPP\LIB" "C:\LOTUS\NOTESAPI\LIB\MSWIN32" "C:\Perl\lib\CORE"
    libs=  oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib  comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib  netapi32.lib uuid.lib wsock32.lib mpr.lib winmm.lib  version.lib odbc32.lib odbccp32.lib msvcrt.lib
    perllibs=  oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib  comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib  netapi32.lib uuid.lib wsock32.lib mpr.lib winmm.lib  version.lib odbc32.lib odbccp32.lib msvcrt.lib
    libc=msvcrt.lib, so=dll, useshrplib=yes, libperl=perl56.lib
  Dynamic Linking:
    dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
    cccdlflags=' ', lddlflags='-dll -nologo -nodefaultlib -release  -libpath:"C:/Perl\lib\CORE"  -machine:x86'

Locally applied patches:
    ACTIVEPERL_LOCAL_PATCHES_ENTRY


@INC for perl v5.6.1:
    C:/perl/lib
    C:/perl/site/lib
    .


Environment for perl v5.6.1:
    HOME=%USERPROFILE%
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=C:\Perl\bin\;C:\WINNT\system32;C:\WINNT;C:\WINNT\System32\Wbem;C:\LOTUS\NOTES5;C:\VCPP\BIN;C:\Cygwin\bin;C:\orant\bin;C:\Batch;C:\usr\bin;C:\Program Files\Common Files\Adaptec Shared\System;c:\sun\jdk1.3.1\bin
    PERL_BADLANG (unset)
    SHELL (unset)

Joshua b. Jore -{ weird geeky madness }-> http://www.greentechnologist.org


@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Sep 22, 2002

From @hvds

Josh b Jore (via RT) <perlbug@​perl.org> wrote​:
:The mg_len attribute is set to -1 after local() is applied
:to a PVMG with 'g' magic. This is how pos() works so really local()
:breaks pos(). I reproduced the problem on cygwin perl 5.8.0 and
:OpenBSD 3.1 perl 5.6.1.

Thanks for the report. This is a known problem, but we haven't yet
worked out how to go about solving it. The underlying issue is that
we don't have any specification for what should happen to magic
when we localise, and all the definitions we've looked at so far
would break someone else's code somewhere (usually by changing the
expected effects for "user" magic, used by applications such as Tk,
or for tied objects).

As part of the 5.9 development process (leading to 5.10.0) I hope
to pursue this issue further, but I'm not sure any one person at the
moment knows enough to state definitively whether it is even in
principle possible to devise a solution that is both general and
correct.

Hugo van der Sanden

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Sep 26, 2002

From josh@greentechnologist.org

On 22 Sep 2002, Hugo van der Sanden wrote​:

Josh b Jore (via RT) <perlbug@​perl.org> wrote​:
:The mg_len attribute is set to -1 after local() is applied
:to a PVMG with 'g' magic. This is how pos() works so really local()
:breaks pos(). I reproduced the problem on cygwin perl 5.8.0 and
:OpenBSD 3.1 perl 5.6.1.

Thanks for the report. This is a known problem, but we haven't yet
worked out how to go about solving it. The underlying issue is that
we don't have any specification for what should happen to magic
when we localise, and all the definitions we've looked at so far
would break someone else's code somewhere (usually by changing the
expected effects for "user" magic, used by applications such as Tk,
or for tied objects).

As part of the 5.9 development process (leading to 5.10.0) I hope
to pursue this issue further, but I'm not sure any one person at the
moment knows enough to state definitively whether it is even in
principle possible to devise a solution that is both general and
correct.

Thank you for the information. I'll tell the ActiveState list where this
was wondered about previously.

Joshua b. Jore -{ weird geeky madness }-> http​://www.greentechnologist.org

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 10, 2004

From @schwern

[gbarr - Wed Aug 07 14​:53​:09 2002]​:

This is still true in 5.8.0

And in 5.8.5 as well as bleadperl@​22511

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jan 18, 2006

From guest@guest.guest.xxxxxxxx

And in 5.8.6 ... is anybody plan to fix this bug? or this is a feature?

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Nov 17, 2006

From @demerphq

This is still open in blead. Does anybody understand why or where the
mg_len gets clobbered? The mg struct otherwise comes through unscathed
so there must be something we can do about the mg_len.

Note, its not really a regex bug, its an error in how we handle magic
during localization. IMO we should be able to find a workaround for
pos() even if Hugo is right that there isnt a general solution.

1 similar comment
@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Nov 17, 2006

From @demerphq

This is still open in blead. Does anybody understand why or where the
mg_len gets clobbered? The mg struct otherwise comes through unscathed
so there must be something we can do about the mg_len.

Note, its not really a regex bug, its an error in how we handle magic
during localization. IMO we should be able to find a workaround for
pos() even if Hugo is right that there isnt a general solution.

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Nov 17, 2006

From @iabyn

On Fri, Nov 17, 2006 at 03​:40​:05AM -0800, yves orton via RT wrote​:

This is still open in blead. Does anybody understand why or where the
mg_len gets clobbered? The mg struct otherwise comes through unscathed
so there must be something we can do about the mg_len.

Note, its not really a regex bug, its an error in how we handle magic
during localization. IMO we should be able to find a workaround for
pos() even if Hugo is right that there isnt a general solution.

[without having looked at the original bug report.. ]
Some while back I did a lot of work on fixing magic with localisation, and
I seem to recall that there was still some more work that was required to
sort pos().

So, assume it's on my todo LIST.

--
Never do today what you can put off till tomorrow.

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Mar 20, 2007

From @smpeters

On Fri Nov 17 04​:16​:31 2006, davem wrote​:

On Fri, Nov 17, 2006 at 03​:40​:05AM -0800, yves orton via RT wrote​:

This is still open in blead. Does anybody understand why or where the
mg_len gets clobbered? The mg struct otherwise comes through unscathed
so there must be something we can do about the mg_len.

Note, its not really a regex bug, its an error in how we handle magic
during localization. IMO we should be able to find a workaround for
pos() even if Hugo is right that there isnt a general solution.

[without having looked at the original bug report.. ]
Some while back I did a lot of work on fixing magic with localisation, and
I seem to recall that there was still some more work that was required to
sort pos().

So, assume it's on my todo LIST.

Fortunately, Duke Nuke 'Em Forever seems as far off as ever ;)

Is this problem resolved now, is there still something more to it to fixed?

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Mar 20, 2007

From @iabyn

On Mon, Mar 19, 2007 at 08​:39​:28PM -0700, Steve Peters via RT wrote​:

On Fri Nov 17 04​:16​:31 2006, davem wrote​:

On Fri, Nov 17, 2006 at 03​:40​:05AM -0800, yves orton via RT wrote​:

This is still open in blead. Does anybody understand why or where the
mg_len gets clobbered? The mg struct otherwise comes through unscathed
so there must be something we can do about the mg_len.

Note, its not really a regex bug, its an error in how we handle magic
during localization. IMO we should be able to find a workaround for
pos() even if Hugo is right that there isnt a general solution.

[without having looked at the original bug report.. ]
Some while back I did a lot of work on fixing magic with localisation, and
I seem to recall that there was still some more work that was required to
sort pos().

So, assume it's on my todo LIST.

Fortunately, Duke Nuke 'Em Forever seems as far off as ever ;)

Is this problem resolved now, is there still something more to it to fixed?

It's resolved

--
My get-up-and-go just got up and went.

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Mar 20, 2007

@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.