[32634] in Perl-Users-Digest
Perl-Users Digest, Issue: 3909 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Mar 25 03:09:25 2013
Date: Mon, 25 Mar 2013 00:09:09 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Mon, 25 Mar 2013 Volume: 11 Number: 3909
Today's topics:
Re: 'Needless flexibilities' and structured records [ve <derykus@gmail.com>
Re: 'Needless flexibilities' and structured records [ve <rweikusat@mssgmbh.com>
Re: 'Needless flexibilities' and structured records [ve <rweikusat@mssgmbh.com>
Re: 'Needless flexibilities' and structured records [ve <derykus@gmail.com>
Re: 'Needless flexibilities' and structured records [ve <ben@morrow.me.uk>
CGI::Carp fatalsToBrowser alternative <xhoster@gmail.com>
How old is he? <xhoster@gmail.com>
Re: How old is he? <xhoster@gmail.com>
Re: Issue: unexpected value in $2 (Perl 5.10.1) <john@castleamber.com>
Re: Issue: unexpected value in $2 (Perl 5.10.1) <klaus03@gmail.com>
Re: Issue: unexpected value in $2 (Perl 5.10.1) <john@castleamber.com>
Re: Issue: unexpected value in $2 (Perl 5.10.1) <klaus03@gmail.com>
Re: Issue: unexpected value in $2 (Perl 5.10.1) <klaus03@gmail.com>
Re: Issue: unexpected value in $2 (Perl 5.10.1) <rweikusat@mssgmbh.com>
Re: Issue: unexpected value in $2 (Perl 5.10.1) <hjp-usenet3@hjp.at>
Re: Issue: unexpected value in $2 (Perl 5.10.1) <ben@morrow.me.uk>
Re: Issue: unexpected value in $2 (Perl 5.10.1) <whynot@pozharski.name>
Re: Issue: unexpected value in $2 (Perl 5.10.1) <ben@morrow.me.uk>
Re: Issue: unexpected value in $2 (Perl 5.10.1) (Randal L. Schwartz)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sat, 23 Mar 2013 08:40:37 -0700 (PDT)
From: "C.DeRykus" <derykus@gmail.com>
Subject: Re: 'Needless flexibilities' and structured records [very long]
Message-Id: <a0396a53-09e5-4158-ae93-abe33a117725@googlegroups.com>
On Friday, March 15, 2013 1:05:44 PM UTC-7, Rainer Weikusat wrote:
> ...
> A possible way would be to prefix the package name to each property
>
> name and hope that all other packages also do this. But since package
>
> names are often longish, this is an unwiedly workaround. A workaround
>
> for the workaround would be to use declared constants whose values are
>
> the long property names and whose names are short enough to be used
>
> comfortably. But - alas - the {} autoquotes the key if it 'looks like
>
> a string' and this means that
>
>
> use constant NAME => __PACKAGE__.'name';
>
>
>
> $h->{NAME} = 'Paul';
>
> doesn't work. A workaround for the workaround for the workaround would
>
> be to invoke the 'constant subroutine' explicitly,
>
>
>
> $h->{NAME()} = 'Paul';
>
>
> but the two added noise characters are rather ugly.
>
Maybe a sightly prettier workaround for auto-quoting
and all the sub calls...
use CONSTANT NAME => __PACKAGE__ . 'name';
$h->{+NAME} = 'Paul';
--> $VAR1 = {
'main::name' => 'Paul'
};
>
> Lastly, the hash lookup which is a rather costly operation happens
>
> every time such a named property is accessed.
> ...
--
Charles DeRykus
------------------------------
Date: Sat, 23 Mar 2013 19:18:15 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: 'Needless flexibilities' and structured records [very long]
Message-Id: <87hak2ylfs.fsf@sapphire.mobileactivedefense.com>
"C.DeRykus" <derykus@gmail.com> writes:
> On Friday, March 15, 2013 1:05:44 PM UTC-7, Rainer Weikusat wrote:
[...]
>> use constant NAME => __PACKAGE__.'name';
>>
>> $h->{NAME} = 'Paul';
>>
>> doesn't work. A workaround for the workaround for the workaround would
> be to invoke the 'constant subroutine' explicitly,
>>
>> $h->{NAME()} = 'Paul';
[...]
> Maybe a sightly prettier workaround for auto-quoting
> and all the sub calls...
>
> use CONSTANT NAME => __PACKAGE__ . 'name';
> $h->{+NAME} = 'Paul';
Something which also works, although I'm not sure if this is
intentional:
$h->{NAME,}
------------------------------
Date: Sun, 24 Mar 2013 14:11:10 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: 'Needless flexibilities' and structured records [very long]
Message-Id: <87mwtszy4h.fsf@sapphire.mobileactivedefense.com>
Rainer Weikusat <rweikusat@mssgmbh.com> writes:
> "C.DeRykus" <derykus@gmail.com> writes:
>> On Friday, March 15, 2013 1:05:44 PM UTC-7, Rainer Weikusat wrote:
>
> [...]
>
>>> use constant NAME => __PACKAGE__.'name';
>>>
>>> $h->{NAME} = 'Paul';
>>>
>>> doesn't work. A workaround for the workaround for the workaround would
>> be to invoke the 'constant subroutine' explicitly,
>>>
>>> $h->{NAME()} = 'Paul';
>
> [...]
>
>> Maybe a sightly prettier workaround for auto-quoting
>> and all the sub calls...
>>
>> use CONSTANT NAME => __PACKAGE__ . 'name';
>> $h->{+NAME} = 'Paul';
>
> Something which also works, although I'm not sure if this is
> intentional:
>
> $h->{NAME,}
... but this is generally not a good idea (which leads to another
disadvantage of hashes for emulating structures): Since $h->{NAME} is
a valid expression in its own right, accidentally omitting the , (or
+) possibly means using an 'unintended' key for storing or accessing a
certain property. A similar issue exists for 'plain string keys'
because a name with a typo is as good a hash key as any other
string. Since 'objects properties' are really nothing but a
generalization of 'global variable sets'[*], that is 'modifiable objects
multiple cooperating subsroutines used for storing shared state
information', this becomes especially nasty when dealing with code
written by someone else ('someone else' here includes 'code one has
written oneself some months or even years ago'): The only way to
determine if a particular instance of
$h->{some_name}
is using the intended key string or an erroneous one is to examine all
code which might use the object in order to find all 'similar keys'
and then make an educated guess based on the information determined in
this way. Yet another 'similar problem' exists for 'accessor methods'
because lookup of these is also based on searching for a string key in
some set of hash tables: An accidentally misspelled method on a rarely
executed codepath will go unnoticed until this codepath is executed
and then, a fatal runtime error will occur.
In contrast to this, declaring property names as constants and using
these constant for accessing array slots implies that misspellings etc
will cause compile-time errors (when using strict as part of the
compilation).
[*] Another fact 'many people' who pay very demonstrative lip service to
"global variables are BAD" refuse to understand (Or claim to be
unable to understand. I haven't yet made up my mind on whether this is
a genuine incapability to see structural similarities in superficially
different things or a case of 'playing dumb' in the hope that
'stubborn denial' combined with 'suitable' personal attacks will at
least be sufficient to confuse someone).
------------------------------
Date: Sun, 24 Mar 2013 21:19:02 -0700 (PDT)
From: "C.DeRykus" <derykus@gmail.com>
Subject: Re: 'Needless flexibilities' and structured records [very long]
Message-Id: <a17237d8-de1c-4118-9142-942df53651b1@googlegroups.com>
On Sunday, March 24, 2013 7:11:10 AM UTC-7, Rainer Weikusat wrote:
> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>
> > "C.DeRykus" <derykus@gmail.com> writes:
>
> >> On Friday, March 15, 2013 1:05:44 PM UTC-7, Rainer Weikusat wrote:
>
> >
>
> > [...]
>
> >
>
> >>> use constant NAME => __PACKAGE__.'name';
>
> >>>
>
> >>> $h->{NAME} = 'Paul';
>
> >>>
>
> >>> doesn't work. A workaround for the workaround for the workaround would
>
> >> be to invoke the 'constant subroutine' explicitly,
>
> >>>
>
> >>> $h->{NAME()} = 'Paul';
>
> >
>
> > [...]
>
> >
>
> >> Maybe a sightly prettier workaround for auto-quoting
>
> >> and all the sub calls...
>
> >>
>
> >> use CONSTANT NAME => __PACKAGE__ . 'name';
>
> >> $h->{+NAME} = 'Paul';
>
> >
>
> > Something which also works, although I'm not sure if this is
>
> > intentional:
>
> >
>
> > $h->{NAME,}
>
>
>
> ... but this is generally not a good idea (which leads to another
>
> disadvantage of hashes for emulating structures): Since $h->{NAME} is
>
> a valid expression in its own right, accidentally omitting the , (or
>
> +) possibly means using an 'unintended' key for storing or accessing a
>
> certain property. A similar issue exists for 'plain string keys'
>
> because a name with a typo is as good a hash key as any other
>
> string. Since 'objects properties' are really nothing but a
>
> generalization of 'global variable sets'[*], that is 'modifiable objects
>
> multiple cooperating subsroutines used for storing shared state
>
> information', this becomes especially nasty when dealing with code
>
> written by someone else ('someone else' here includes 'code one has
>
> written oneself some months or even years ago'): The only way to
>
> determine if a particular instance of
>
>
>
> $h->{some_name}
>
>
>
> is using the intended key string or an erroneous one is to examine all
>
> code which might use the object in order to find all 'similar keys'
>
> and then make an educated guess based on the information determined in
>
> this way. Yet another 'similar problem' exists for 'accessor methods'
>
> because lookup of these is also based on searching for a string key in
>
> some set of hash tables: An accidentally misspelled method on a rarely
>
> executed codepath will go unnoticed until this codepath is executed
>
> and then, a fatal runtime error will occur.
>
>
>
> In contrast to this, declaring property names as constants and using
>
> these constant for accessing array slots implies that misspellings etc
>
> will cause compile-time errors (when using strict as part of the
>
> compilation).
>
> ...
I regretted the post almost immediately for several reasons.
However, I was surprised by these exceptions to these hash key
auto-quoting twists. It seems very odd that the trailing ","
(multi-dimensional array emulation) would work at all. Ditto
for the pre-pended "+". No idea why.
--
Charles DeRykus
array emulation)
to cause multi-dim. emulation
------------------------------
Date: Mon, 25 Mar 2013 06:05:41 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: 'Needless flexibilities' and structured records [very long]
Message-Id: <l2652a-bkv1.ln1@anubis.morrow.me.uk>
Quoth "C.DeRykus" <derykus@gmail.com>:
>
> I regretted the post almost immediately for several reasons.
>
> However, I was surprised by these exceptions to these hash key
> auto-quoting twists. It seems very odd that the trailing ","
> (multi-dimensional array emulation) would work at all. Ditto
> for the pre-pended "+". No idea why.
Anything inside the {} which doesn't match \w causes the contents to be
interpreted as an expression rather than a string. C<+NAME> and C<NAME,>
are both perfectly valid expressions which call the sub NAME: the + is
the unary 'term' operator, which does exactly nothing and is
occasionally useful to persuade Perl to choose one interpretation of an
ambiguous expression rather than another; the , is an ordinary trailing-
comma-on-the-end-of-a-list, which is eaten by the parser and doesn't add
an extra element.
The one thing that is slightly weird is that $h{NAME,} calls NAME in
scalar context, despite the comma. I think what is happening here is
that the code which decides whether this is a single- or multi-dim
subscript just looks at the number of expressions in its argument list,
by which time that comma has long since disappeared.
Ben
------------------------------
Date: Sat, 23 Mar 2013 21:46:23 -0700
From: Xho Jingleheimerschmidt <xhoster@gmail.com>
Subject: CGI::Carp fatalsToBrowser alternative
Message-Id: <kim0bl$v7d$1@dont-email.me>
I'd like a kinder, gentler version of the die implemented by CGI::Carp
qw(fatalsToBrowser), for calling explicitly when I detect invalid user
input of some sort. I can use the existing features of CGI::Carp to
change the footer for the message displayed, but can't seem to change
the header of "Software error:" to be something more like "Invalid user
input, please fix and try again:"
I'd like to keep the other features of CGI::Carp's die if I can, like
teeing to stderr with a timestamp, printing a header if necessary,
protecting special characters in the message, and the things that I
don't understand which seem to be designed to work with MOD_PERL.
Is the best bet just to copy fatalsToBrowser and make some changes to
the copy?
Xho
------------------------------
Date: Sat, 23 Mar 2013 21:20:03 -0700
From: Xho Jingleheimerschmidt <xhoster@gmail.com>
Subject: How old is he?
Message-Id: <kiluqb$qsc$1@dont-email.me>
A few doors down from me is this little kid named Vinnie. Whenever he
sees me, he says "Hi", or more like "Hiiiiiiiiiiiiii". And then he
keeps doing it until I say hi back in this overly dramatic sing-songie
voice. Just a normal "Hey" won't cut it. And then it goes the same,
only with "bye" instead of "hi".
So is this one of the Keebler Elves Ross Geller Peugeot Citroen Mellon
stages, or is the kid just a freak? And should I humor his neuroses, or
not?
Xho
--
As far as I know, he has never shot down an Iranian passenger airliner.
------------------------------
Date: Sat, 23 Mar 2013 21:27:04 -0700
From: Xho Jingleheimerschmidt <xhoster@gmail.com>
Subject: Re: How old is he?
Message-Id: <kilvk8$t86$1@dont-email.me>
On 03/23/2013 09:20 PM, Xho Jingleheimerschmidt wrote:
Sorry, obviously meant for a different destination.
------------------------------
Date: Fri, 22 Mar 2013 20:58:45 -0600
From: John Bokma <john@castleamber.com>
Subject: Re: Issue: unexpected value in $2 (Perl 5.10.1)
Message-Id: <87y5deu8ii.fsf@castleamber.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth John Bokma <john@castleamber.com>:
>>
>> The following piece of code assigns an unexpected value to $2 in a
>> program I am working on. When I run tests, it works as expected, but
>> when I run the actual program (which parses currently 2 large XML files)
>> $2 gets assigned a random value when the second XML file is parsed [1]:
>>
>> $iso_gmt =~ /^(\d{4})-(\d\d)-(\d\d)T(\d\d):(\d\d):(\d\d)Z$/
>> or croak "Not a valid ISO GMT date time: '$iso_gmt'";
>> # Note: without the assingment below $2 might be set to a different
>> # value for an unknown reason (bug in XML::Parser C code?)
>> # perl, v5.10.1
>> #my $month = $2;
>> my $seconds_since_epoch;
>> my $error;
>> $seconds_since_epoch = timegm( $6, $5, $4, $3, $2 - 1, $1 - 1900 );
>
> This code doesn't call XML::Parser. Where are you calling it?
My apologies for the unclear write up. The above piece of code is called
by code that uses XML::Parser to parse two XML files. Since the issue
seems to depend on the order in which the XML files are parsed I don't
think it's possible (or: easy) to create a minimal test case (otherwise
I certainly would've posted that one). Note: tests that I run via prove
to test the above code don't show the issue.
> Also, I would usually want to assign the return value of m// rather than
> relying on globals:
Yes, same here, usually ;-).
>> Examples of errors:
>>
>> Month '20129103' out of range 0..11
>> Month '11826511' out of range 0..11
>> Month '20079951' out of range 0..11
>> Month '15160655' out of range 0..11
>> Month '21972303' out of range 0..11
>> Month '10208591' out of range 0..11
>>
>> 0133254f - 20129103
>> 00b4754f - 11826511
>> 0132654f - 20079951
>> 00e7554f - 15160655
>> 014f454f - 21972303
>> 009bc54f - 10208591
>>
>> ^^^ looks like there is a pattern.
>
> Where does this output come from?
timegm throws the "Month ... out of range ...". I used a one liner to
convert those values to hex (given above).
[..]
> The output of Devel::Peek::Dump($2) at various points would be helpful.
> If you can it would also be worth trying with a perl built with
> -DDEBUGGING, to see if you get an assertion failure.
Thanks, will look into those two options. Right now I am not able to
reproduce it. Most likely due to code changes.
--
John Bokma j3b
Blog: http://johnbokma.com/ Perl Consultancy: http://castleamber.com/
Perl for books: http://johnbokma.com/perl/help-in-exchange-for-books.html
------------------------------
Date: Sat, 23 Mar 2013 06:06:35 -0700 (PDT)
From: Klaus <klaus03@gmail.com>
Subject: Re: Issue: unexpected value in $2 (Perl 5.10.1)
Message-Id: <909786a5-2ccd-48aa-bd6e-8a82e16340a5@r1g2000yql.googlegroups.com>
On 23 mar, 00:44, Ben Morrow <b...@morrow.me.uk> wrote:
> Quoth John Bokma <j...@castleamber.com>:
> > =A0 =A0 $iso_gmt =3D~ /^(\d{4})-(\d\d)-(\d\d)T(\d\d):(\d\d):(\d\d)Z$/
> > =A0 =A0or croak "Not a valid ISO GMT date time: '$iso_gmt'";
> Also, I would usually want to assign the return value of m// rather than
> relying on globals:
> =A0 =A0 my ($year, $month, $day, $hour, $min, $sec) =3D
> =A0 =A0 =A0 =A0 $iso_gmt =3D~ /.../;
I agree, but I would also add that it is perfectly safe to use $1, $2,
$3, ... in an assignment to local variables immediatly after $iso_gmt
=3D~ /.../ or croak "..."
For example, the following lines are perfectly safe:
$iso_gmt =3D~ /.../ or croak "...";
my ($year, $month, $day, $hour, $min, $sec)
=3D ($1, $2, $3, $4, $5, $6);
However, the following line is not safe:
> > $seconds_since_epoch =3D timegm( $6, $5, $4, $3, $2 - 1, $1 - 1900 );
I am very suspicious about the fact that $1, $2, $3, ... are passed by
reference to a subroutine timegm( $6, $5, $4, $3, $2 - 1, $1 - 1900 ).
Variables such as $1, $2, $3, ... have very complicated scoping rules.
Passing such variables by reference to a subroutine makes it very hard
to guarantee the integrity of $1, $2, $3, ...
------------------------------
Date: Sat, 23 Mar 2013 09:01:18 -0600
From: John Bokma <john@castleamber.com>
Subject: Re: Issue: unexpected value in $2 (Perl 5.10.1)
Message-Id: <87ehf6cg8x.fsf@castleamber.com>
Klaus <klaus03@gmail.com> writes:
> However, the following line is not safe:
>
>> > $seconds_since_epoch = timegm( $6, $5, $4, $3, $2 - 1, $1 - 1900 );
Can you give me an example of calling a sub that shows this unsafe
behavior? And/or the scoping issues you mention?
I've always considered it perfectly safe to do something like:
$foo =~ /(.)/;
bar( $1 );
if not, I like to know cases this can go wrong. Thanks.
--
John Bokma j3b
Blog: http://johnbokma.com/ Perl Consultancy: http://castleamber.com/
Perl for books: http://johnbokma.com/perl/help-in-exchange-for-books.html
------------------------------
Date: Sat, 23 Mar 2013 09:10:39 -0700 (PDT)
From: Klaus <klaus03@gmail.com>
Subject: Re: Issue: unexpected value in $2 (Perl 5.10.1)
Message-Id: <3727ca15-8550-4714-835d-65e8f8c6dd10@p5g2000yqj.googlegroups.com>
On 23 mar, 16:01, John Bokma <j...@castleamber.com> wrote:
> Klaus <klau...@gmail.com> writes:
> > However, the following line is not safe:
>
> >> > $seconds_since_epoch = timegm( $6, $5, $4, $3, $2 - 1, $1 - 1900 );
>
> Can you give me an example of calling a sub that shows this unsafe
> behavior? And/or the scoping issues you mention?
>
> I've always considered it perfectly safe to do something like:
>
> $foo =~ /(.)/;
> bar( $1 );
>
> if not, I like to know cases this can go wrong. Thanks.
Here is an example where
Case 1 uses the safe bar($var)
Case 2 uses the unsafe bar($1)
==============================================
use strict;
use warnings;
my $foo = 'abc';
$foo =~ /^(..).$/ or die "Error 1";
my $var = $1;
print "Case 1: ", bar($var), "\n";
$foo =~ /^(..).$/ or die "Error 2";
print "Case 2: ", bar($1), "\n";
sub bar {
my $z = '';
$_[0] =~ /^(.).$/ or return "Error 3";
$z .= $1;
$_[0] =~ /^.(.)$/ or return "Error 4";
$z .= $1;
return "ok ('$z')";
}
==============================================
The output is:
==============================================
Case 1: ok ('ab')
Case 2: Error 4
==============================================
------------------------------
Date: Sat, 23 Mar 2013 09:36:17 -0700 (PDT)
From: Klaus <klaus03@gmail.com>
Subject: Re: Issue: unexpected value in $2 (Perl 5.10.1)
Message-Id: <881c9239-4cec-48b1-b2ac-536fb2c59874@n2g2000yqg.googlegroups.com>
On 23 mar, 16:01, John Bokma <j...@castleamber.com> wrote:
> Klaus <klau...@gmail.com> writes:
> > However, the following line is not safe:
> >> > $seconds_since_epoch = timegm( $6, $5, $4, $3, $2 - 1, $1 - 1900 );
> And/or the scoping issues you mention?
see perldoc perlre:
++ These special variables, like the %+ hash and the numbered match
++ variables ($1 , $2 , $3 , etc.) are dynamically scoped until the
++ end of the enclosing block or until the next successful match,
++ whichever comes first.
The scoping issue is that the execution of timegm($6, ...) falls in
the same dynamically scoped block as the previously executed $iso_gmt
=~ /.../ or croak "...";
timegm($6, ...) can itself have regular expressions, in which case
that regular expression overwrites whatever is contained in $6.
The issue is that $6 is aliased to the first parameter of
timegm($6, ...).
These cases are not necessarily wrong, but they are very difficult to
get right.
------------------------------
Date: Sat, 23 Mar 2013 18:49:30 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Issue: unexpected value in $2 (Perl 5.10.1)
Message-Id: <87li9eymrp.fsf@sapphire.mobileactivedefense.com>
Klaus <klaus03@gmail.com> writes:
[...]
> ==============================================
> use strict;
> use warnings;
>
> my $foo = 'abc';
>
> $foo =~ /^(..).$/ or die "Error 1";
> my $var = $1;
> print "Case 1: ", bar($var), "\n";
>
> $foo =~ /^(..).$/ or die "Error 2";
> print "Case 2: ", bar($1), "\n";
>
> sub bar {
> my $z = '';
>
> $_[0] =~ /^(.).$/ or return "Error 3";
> $z .= $1;
'use warnings' wouldn't complain about .= with a 'no value' variable
on the left hand side and even if this wasn't the case, the useless
concatenation could simply be replaced with a proper assignment in
order to avoid the "cargo cult 'initialization'" (my $z = '').
------------------------------
Date: Sat, 23 Mar 2013 20:31:50 +0100
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: Issue: unexpected value in $2 (Perl 5.10.1)
Message-Id: <slrnkks0p6.c96.hjp-usenet3@hrunkner.hjp.at>
On 2013-03-23 16:36, Klaus <klaus03@gmail.com> wrote:
> On 23 mar, 16:01, John Bokma <j...@castleamber.com> wrote:
>> Klaus <klau...@gmail.com> writes:
>> > However, the following line is not safe:
>> >> > $seconds_since_epoch = timegm( $6, $5, $4, $3, $2 - 1, $1 - 1900 );
>
>> And/or the scoping issues you mention?
>
> see perldoc perlre:
>
> ++ These special variables, like the %+ hash and the numbered match
> ++ variables ($1 , $2 , $3 , etc.) are dynamically scoped until the
> ++ end of the enclosing block or until the next successful match,
> ++ whichever comes first.
>
> The scoping issue is that the execution of timegm($6, ...) falls in
> the same dynamically scoped block as the previously executed $iso_gmt
>=~ /.../ or croak "...";
>
> timegm($6, ...) can itself have regular expressions, in which case
> that regular expression overwrites whatever is contained in $6.
While that is theoretically possible, it doesn't seem to be the case
with timegm(). I just skimmed the source and don't see any use of
regexps there and frankly I can't think of any legitimate use timegm()
could have for regexps.
> The issue is that $6 is aliased to the first parameter of
> timegm($6, ...).
So I doubt that this is the issue. (Also I think John would have been
able to extract a minimal test case if it was that easy)
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | Sysadmin WSR | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
------------------------------
Date: Sat, 23 Mar 2013 22:30:26 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Issue: unexpected value in $2 (Perl 5.10.1)
Message-Id: <21n12a-7cu.ln1@anubis.morrow.me.uk>
Quoth "Peter J. Holzer" <hjp-usenet3@hjp.at>:
> On 2013-03-23 16:36, Klaus <klaus03@gmail.com> wrote:
> >
> > timegm($6, ...) can itself have regular expressions, in which case
> > that regular expression overwrites whatever is contained in $6.
>
> While that is theoretically possible, it doesn't seem to be the case
> with timegm(). I just skimmed the source and don't see any use of
> regexps there and frankly I can't think of any legitimate use timegm()
> could have for regexps.
$year =~ /^[0-9]+$/ or croak "invalid year value";
? I agree that it doesn't appear to do this.
> > The issue is that $6 is aliased to the first parameter of
> > timegm($6, ...).
>
> So I doubt that this is the issue. (Also I think John would have been
> able to extract a minimal test case if it was that easy)
I agree; I suspect this is either an XML::Parser C bug or a core C bug,
but without more information it's impossible to be sure.
Ben
------------------------------
Date: Sun, 24 Mar 2013 12:15:22 +0200
From: Eric Pozharski <whynot@pozharski.name>
Subject: Re: Issue: unexpected value in $2 (Perl 5.10.1)
Message-Id: <slrnkktkhq.jjo.whynot@orphan.zombinet>
with <87ehf6cg8x.fsf@castleamber.com> John Bokma wrote:
> Klaus <klaus03@gmail.com> writes:
>
>> However, the following line is not safe:
>>
>>> > $seconds_since_epoch = timegm( $6, $5, $4, $3, $2 - 1, $1 - 1900 );
>
> Can you give me an example of calling a sub that shows this unsafe
> behavior? And/or the scoping issues you mention?
#!/usr/bin/perl
use strict;
use warnings;
use feature qw{ say };
sub holy_cosmos {
my $input = shift @_;
'holy_hallelujah' =~ m{holy_(.*)};
say $1 // 'missing'
}
'holy_rainbow' =~ m{(.*)_(.*)};
say $1 // 'not found';
holy_cosmos $1;
say $1 // 'not found';
__END__
{2109:6} [0:0]% perl ~/foo.90HmzN.pl
holy
hallelujah
holy
{2374:7} [0:0]%
I doubt there's any. Probably, that was the case in pre-historic Perls.
Or this is some XS that directly manipulates variables in other scope.
*CUT*
--
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom
------------------------------
Date: Sun, 24 Mar 2013 12:13:01 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Issue: unexpected value in $2 (Perl 5.10.1)
Message-Id: <d7732a-ekc1.ln1@anubis.morrow.me.uk>
Quoth Eric Pozharski <whynot@pozharski.name>:
> with <87ehf6cg8x.fsf@castleamber.com> John Bokma wrote:
> > Klaus <klaus03@gmail.com> writes:
> >
> >> However, the following line is not safe:
> >>
> >>> > $seconds_since_epoch = timegm( $6, $5, $4, $3, $2 - 1, $1 - 1900 );
> >
> > Can you give me an example of calling a sub that shows this unsafe
> > behavior? And/or the scoping issues you mention?
>
> #!/usr/bin/perl
>
> use strict;
> use warnings;
> use feature qw{ say };
>
> sub holy_cosmos {
> my $input = shift @_;
> 'holy_hallelujah' =~ m{holy_(.*)};
> say $1 // 'missing'
> }
>
> 'holy_rainbow' =~ m{(.*)_(.*)};
> say $1 // 'not found';
> holy_cosmos $1;
> say $1 // 'not found';
>
> __END__
>
> {2109:6} [0:0]% perl ~/foo.90HmzN.pl
> holy
> hallelujah
> holy
> {2374:7} [0:0]%
>
> I doubt there's any. Probably, that was the case in pre-historic Perls.
Try this:
sub foo {
my ($x) = @_;
"y" =~ /(.)/;
say "$x:$_[0]";
}
"x" =~ /(.)/;
foo $1;
Note that this can only happen if you access @_ directly (or by
reference) after doing a pattern match, which is not common.
Ben
------------------------------
Date: Sun, 24 Mar 2013 17:36:43 -0700
From: merlyn@stonehenge.com (Randal L. Schwartz)
Subject: Re: Issue: unexpected value in $2 (Perl 5.10.1)
Message-Id: <86y5dc1fj8.fsf@red.stonehenge.com>
>>>>> "Eric" == Eric Pozharski <whynot@pozharski.name> writes:
Eric> sub holy_cosmos {
Eric> my $input = shift @_;
Eric> 'holy_hallelujah' =~ m{holy_(.*)};
Eric> say $1 // 'missing'
Eric> }
This is bad. Very bad. If the match fails, it DOES NOT RESET the match
variables. So you have broken code from the getgo.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 3909
***************************************
