From mal@poly-aniline.com

perl 5.8.8
produces incorrect results with provided test2.pl test.

in case of using the line
my($tmpbname)=$a=~m@​<DATA>([^<>]*)@​isg;
The output is incorrect

Use of uninitialized value in concatenation (.) or string at test2.pl
line 28.
TBN= A=<DATA>J1</END>
Use of uninitialized value in concatenation (.) or string at test2.pl
line 28.
TBN= A=<DATA>J2</END>
Use of uninitialized value in concatenation (.) or string at test2.pl
line 28.
TBN= A=<DATA>J3</END>
Use of uninitialized value in concatenation (.) or string at test2.pl
line 28.
TBN= A=<DATA>J4</END>
Use of uninitialized value in concatenation (.) or string at test2.pl
line 28.
TBN= A=<DATA>J5</END>

when I use the same meaning (commented lines)
my $x=$a;
my($tmpbname)=$x=~m@​<DATA>([^<>]*)@​isg;

The output is correct

TBN=J1 A=<DATA>J1</END>
TBN=J2 A=<DATA>J2</END>
TBN=J3 A=<DATA>J3</END>
TBN=J4 A=<DATA>J4</END>
TBN=J5 A=<DATA>J5</END>

also see https://bugzilla.redhat.com/show_bug.cgi?id=429531

------------ Code for test2.pl
my $ai=[
'<DATA>J1</END>',
'<DATA>J2</END>',
'<DATA>J3</END>',
'<DATA>J4</END>',
'<DATA>J5</END>'
];

sub test($)
{
  my($apts)=@​_;

  foreach my $a (@​$apts)
  {
  if($a!~m@​^<DATA>@​isg)
  {
  next;
  }
  my $d={};
  # DOES NOT WORK
  my($tmpbname)=$a=~m@​<DATA>([^<>]*)@​isg;

  ## WORKS
  #my $x=$a;
  #my($tmpbname)=$x=~m@​<DATA>([^<>]*)@​isg;

  print{*STDERR} "TBN=$tmpbname A=$a\n";
  }
}

test($ai);

From @Abigail

On Mon, Jan 21, 2008 at 11​:06​:02AM -0800, Vladislav Malyshkin wrote​:

# New Ticket Created by Vladislav Malyshkin
# Please include the string​: [perl #50072]
# in the subject line of all future correspondence about this issue.
# <URL​: http​://rt.perl.org/rt3/Ticket/Display.html?id=50072 >

perl 5.8.8
produces incorrect results with provided test2.pl test.

in case of using the line
my($tmpbname)=$a=~m@​<DATA>([^<>]*)@​isg;
The output is incorrect

Use of uninitialized value in concatenation (.) or string at test2.pl
line 28.
TBN= A=<DATA>J1</END>
Use of uninitialized value in concatenation (.) or string at test2.pl
line 28.
TBN= A=<DATA>J2</END>
Use of uninitialized value in concatenation (.) or string at test2.pl
line 28.
TBN= A=<DATA>J3</END>
Use of uninitialized value in concatenation (.) or string at test2.pl
line 28.
TBN= A=<DATA>J4</END>
Use of uninitialized value in concatenation (.) or string at test2.pl
line 28.
TBN= A=<DATA>J5</END>

when I use the same meaning (commented lines)
my $x=$a;
my($tmpbname)=$x=~m@​<DATA>([^<>]*)@​isg;

The output is correct

TBN=J1 A=<DATA>J1</END>
TBN=J2 A=<DATA>J2</END>
TBN=J3 A=<DATA>J3</END>
TBN=J4 A=<DATA>J4</END>
TBN=J5 A=<DATA>J5</END>

also see https://bugzilla.redhat.com/show_bug.cgi?id=429531

------------ Code for test2.pl
my $ai=[
'<DATA>J1</END>',
'<DATA>J2</END>',
'<DATA>J3</END>',
'<DATA>J4</END>',
'<DATA>J5</END>'
];

sub test($)
{
my($apts)=@​_;

foreach my $a \(@​$apts\)
\{
    if\($a\!~m@&#8203;^\<DATA>@&#8203;isg\)

This is causing your problem. You're succesfully matching $a using the
/g modifier. Which means the position where the next match should start
matching is right after the <DATA>, meaning that your "DOES NOT WORK"
match fails to match.

    \{
        next;
    \}
    my $d=\{\};
    \# DOES NOT WORK
    my\($tmpbname\)=$a=~m@&#8203;\<DATA>\(\[^\<>\]\*\)@&#8203;isg;

    \#\# WORKS
    \#my $x=$a;
    \#my\($tmpbname\)=$x=~m@&#8203;\<DATA>\(\[^\<>\]\*\)@&#8203;isg;

Now you are matching against a copy, which will start scanning from the
beginning, finding the match.

    print\{\*STDERR\} "TBN=$tmpbname A=$a\\n";
\}

}

You seem to be quite eager to use modifiers. In none of your matches
is the /s relevant (there's no .), and even the /i seems unnecessary.
But the killer is the /g in the if. Lose it, and your matches will
succeed.

Abigail

The RT System itself - Status changed from 'new' to 'open'

From mal@poly-aniline.com

What I can say.
For functions to have a side effect - this happens and sometimes unavoidable.

But for OPERATORS to have a side effect
is plain ugly and wrong.

From mal@poly-aniline.com

What I can say.
For functions to have a side effect - this happens and sometimes unavoidable.
But for OPERATORS to have a side effect
is plain ugly and wrong.

From @Abigail

On Thu, Mar 13, 2008 at 05​:38​:52PM -0400, Vladislav Malyshkin wrote​:

What I can say.
For functions to have a side effect - this happens and sometimes
unavoidable.
But for OPERATORS to have a side effect
is plain ugly and wrong.

If operators wouldn't have side effects, s/// would be pretty useless,
and special variables like $1, $2, %+, etc wouldn't exist.

Abigail

From @schwern

Vladislav Malyshkin wrote​:

What I can say.
For functions to have a side effect - this happens and sometimes
unavoidable.
But for OPERATORS to have a side effect
is plain ugly and wrong.

Death to ++!

Also +=, s///, m//, .. and <FILE>. :P

But seriously, while there can be a lively debate about the utility of
side-effects, railing against their use in Perl 5 builtins might be a bit of a
lost cause at this point.

--
125. Two drink limit does not mean two kinds of drinks.
  -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
  http​://skippyslist.com/list/

p5p@spam.wizbit.be - Status changed from 'open' to 'rejected'