[30500] in Perl-Users-Digest
Perl-Users Digest, Issue: 1743 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Jul 23 16:09:51 2008
Date: Wed, 23 Jul 2008 13:09:13 -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 Wed, 23 Jul 2008 Volume: 11 Number: 1743
Today's topics:
Re: C linked lists in Perl <hjp-usenet2@hjp.at>
Re: C linked lists in Perl <hjp-usenet2@hjp.at>
Re: C linked lists in Perl <ben@morrow.me.uk>
Re: comma puzzle <szrRE@szromanMO.comVE>
Re: comma puzzle <szrRE@szromanMO.comVE>
Re: comma puzzle <szrRE@szromanMO.comVE>
Re: how to change the effective user identficator <jimsgibson@gmail.com>
Re: how to change the effective user identficator <szrRE@szromanMO.comVE>
Re: Mail::IMAPClient usage... <tzz@lifelogs.com>
Re: number of maximum decimal places supported with Per <nospam-abuse@ilyaz.org>
PAR packer Error <ezraroi@gmail.com>
Re: PAR packer Error <ben@morrow.me.uk>
Re: Perl for calculating an expression. <nospam-abuse@ilyaz.org>
Re: Perl for calculating an expression. <fawaka@gmail.com>
Re: Perl for calculating an expression. <glennj@ncf.ca>
Re: Perl for calculating an expression. <jurgenex@hotmail.com>
Slow GC before program termination (was: C linked lists <hjp-usenet2@hjp.at>
Re: Slow GC before program termination (was: C linked l <ben@morrow.me.uk>
Undefined behaviour (was: C linked lists in Perl) <hjp-usenet2@hjp.at>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 23 Jul 2008 19:50:11 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: C linked lists in Perl
Message-Id: <slrng8erqn.v16.hjp-usenet2@hrunkner.hjp.at>
On 2008-07-22 18:15, Joost Diepenmaat <joost@zeekat.nl> wrote:
> "Peter J. Holzer" <hjp-usenet2@hjp.at> writes:
>
>> On 2008-07-21 10:16, Joost Diepenmaat <joost@zeekat.nl> wrote:
>>> "szr" <szrRE@szromanMO.comVE> writes:
>>>> Joost Diepenmaat wrote:
>>>>> But expect perl's garbage collector to get in your face if you create
>>>>> giant linked lists. Not that you'd want to do that, anyway.
>>>>
>>>> Why would the GC get in the way? In a nutshell, it doesn't free
>>>> something until no one is referring to it anymore (the ref-count is
>>>> zero), so I'd imagine there would be no problem, or have you run into
>>>> issue in certain circumstances?
>>>
>>> The problem is that perl's CG is buggy
>>
>> Define "buggy".
>
> See below.
[...]
> I think you're correct that the problem is probably related to the
> stack use during GC, but IMHO it's hardly good behaviour that GC'ing a
> large linked structure causes a segfault.
True. I'm hesitating to call it a bug in perl, though: The GC algorithm
works, it just needs quite a bit of memory in an area where the OS
chooses to enforce a rather strict limit (for no good reason AFAICS,
except "it has always been that way, and deeply recursive programs are
probably buggy anyway"). When GC exceeds that limit, the process is
killed by the OS, and there is little perl can do about it. The OS may also
kill the process if it exceeds some other memory limit, although it
shouldn't (however perl doesn't have a way to recover from malloc
returning NULL, either, which one might call a bug).
There is an easy workaround for the limited stack space, and one could
call it a bug that perl isn't using it. But I think it would be quite a
bit slower (obviously I would have to implement and benchmark it to be
sure), and I prefer a faster GC to one which slows down all my scripts
but handles a very unusual case.
So I'd file the GC crash on deeply nested structures under "perl likes
to have lots of memory and it is very unhappy if it can't get it".
If someone wants to improve the GC, I think there are a few much more
important problems, like the lack of cycle detection.
hp
------------------------------
Date: Wed, 23 Jul 2008 20:08:55 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: C linked lists in Perl
Message-Id: <slrng8estq.v16.hjp-usenet2@hrunkner.hjp.at>
On 2008-07-22 18:16, xhoster@gmail.com <xhoster@gmail.com> wrote:
> "Peter J. Holzer" <hjp-usenet2@hjp.at> wrote:
>> who in his right mind builds datastructures with 100000 nesting
>> levels?
>
> Someone trying to implement a large linked list, for one, or course.
However, why would someone do this in Perl? Which problem would be
better solved by a singly linked list than an array in Perl? It just
seems to be unidiomatic.
hp
------------------------------
Date: Wed, 23 Jul 2008 19:36:08 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: C linked lists in Perl
Message-Id: <o9akl5-id5.ln1@osiris.mauzo.dyndns.org>
Quoth "Peter J. Holzer" <hjp-usenet2@hjp.at>:
> shouldn't (however perl doesn't have a way to recover from malloc
> returning NULL, either, which one might call a bug).
See $^M in perlvar. Of course, this is hardly easy to use; but then,
recovering from lack-of-memory is hardly easy under any circumstances.
Ben
--
"Faith has you at a disadvantage, Buffy."
"'Cause I'm not crazy, or 'cause I don't kill people?"
"Both, actually."
[ben@morrow.me.uk]
------------------------------
Date: Wed, 23 Jul 2008 12:11:53 -0700
From: "szr" <szrRE@szromanMO.comVE>
Subject: Re: comma puzzle
Message-Id: <g67vpq01cg@news4.newsguy.com>
Tad J McClellan wrote:
> szr <szrRE@szromanMO.comVE> wrote:
>
>> Yes, exactly. I could of been
>
>
> s/could of/could've/
> or
> s/could of/could have/
>
>
>> Ok, though C<for ( my $i=0 , $i<10 , $i++ ) { print $i; }> would of
>> been caught is use strict were used:
>
>
> s/would of/would've/
> or
> s/would of/would have/
ah, thanks for catching that, common mistake.
--
szr
------------------------------
Date: Wed, 23 Jul 2008 12:17:02 -0700
From: "szr" <szrRE@szromanMO.comVE>
Subject: Re: comma puzzle
Message-Id: <g6803e01ki@news4.newsguy.com>
xhoster@gmail.com wrote:
> "szr" <szrRE@szromanMO.comVE> wrote:
>> xhoster@gmail.com wrote:
>>> "szr" <szrRE@szromanMO.comVE> wrote:
>>>>
>>>> Shouldn't it end up like:
>>>>
>>>> $i=0 -> 0,
>>>
>>> The result of $i=0 is not 0, it is $i. If $i is not changed
>>> elsewhere in the same statement, then $i is 0, but here $i is
>>> changed elsewhere.
>>
>> Yes, the result is $i in that case, which is 0.
>
> When $i (the result of $i=0) is stuffed into the list, it is 0. But
> it is stuffed into the list by alias, not by value, and by the time
> it is retrieved from the list the first time through the loop, it is
> 1.
Maybe I didn't state it clear enough; I indeed meant the _value_ of $i.
Sorry for the confusion.
>>>> $i++ -> 0+1 -> 1
>>>
>>> The value of $i++ is the "prior" value of $i, not the "new" value of
>>> $i.
>>
>> Either way it's going to be 1 right, since $i would start out as 0
>> (ok, undef), and it's being explicitly set to 0, so $i++ would
>> result in the third element being 1.
>
> No, $i++ would result in $i being 1, but that is the side-effect, not
> the value. The value of $i++, and hence the third element, isn't $i,
> it is the thing previously held by $i, in this case zero.
Yes, I know that. It is the element itself (that's what you were taking
the ref of.) Again, I was talking about the _value_. Again, sorry for
the confusion.
> perl -le 'my $i; print \$i; for($i=0,$i<10,$i++){print "$_\t",\$_;}'
>
> SCALAR(0x61c700)
> 1 SCALAR(0x61c700)
> 1 SCALAR(0x6018e0)
> 0 SCALAR(0x6043e0)
--
szr
------------------------------
Date: Wed, 23 Jul 2008 12:36:59 -0700
From: "szr" <szrRE@szromanMO.comVE>
Subject: Re: comma puzzle
Message-Id: <g6818s02pt@news4.newsguy.com>
Tad J McClellan wrote:
> szr <szrRE@szromanMO.comVE> wrote:
>> Tad J McClellan wrote:
>>> Nick Wedd <nick@maproom.co.uk> wrote:
>>>>
>>>> If I do
>>>> for ( my $i=0 ; $i<10 ; $i++ ) { print $i; }
>>>> it writes "0123456789". Fine.
>>>
>>> That uses the control structure described in the "For Loops"
>>> section of perlsyn.pod.
>>>
>>>> Now if I accidentally write
>>>> for ( my $i=0 , $i<10 , $i++ ) { print $i; }
>>>
>>> That uses the control structure described in the "Foreach Loops"
>>> section of perlsyn.pod.
>>>
>>> Since you did not provide a loop control variable, the foreach will
>>> place each list item into $_.
>>>
>>> But you never output $_.
>>>
>>>> it writes "111".
>>>
>>> it outputs "000" when I run it:
>>>
>>> perl -e 'for ( my $i=0 , $i<10 , $i++ ) { print $i; }'
>>
>> It depends if $i is declared ahead of time or not:
>
> I was commenting on the OP's code.
I know, I just wanted to point out how the OP likely had gotten his
results.
>> $ perl -e 'for ( my $i=0 , $i<10 , $i++ ) { print $i; }'
>> 000
>
> That was the OP's code.
Right.
>> $ perl -e 'my $i; for ( $i=0 , $i<10 , $i++ ) { print $i; }'
>> 111
>
> That is not the OP's code.
Right.
>> This is because in the first one, the C<$i> in the 2nd and 3rd
>> elements is not the same one in the first element,
>
> That is what I said.
I don't see an equivilent statement, but maybe it turns out to be like
something you said restated in another way.
>> One question, I would of actually expected
>
>
> s/would of/would've/
> or
> s/would of/would have/
>
>
> I've suspected this for some time.
Suspected what? That typos are made? It's just lazy typing on my part,
which is quite common for anyone having spent enough time in the USA - I
would largely blame TV and Hollywood and even Radio, given that many of
these bad grammatical habits tend to come from sources such as these.
So IMHO, there's little point in making a point of it unless it
completely changes the meaning of what was being said, which clearly
wasn't the case here.
>> the 2nd run (where C<$i> is
>> pre-delcared) to output 011. Why does the first element become 1?
>
> Note that my post pointed out a particular Perl variable
> that is not being output by the OP's code...
The real point of my post was to followup your conclusion that when you
ran the OP's code, you got 000, while he got 111, and I just wanted to
show how the OP might have arrived there.
--
szr
------------------------------
Date: Wed, 23 Jul 2008 10:36:28 -0700
From: Jim Gibson <jimsgibson@gmail.com>
Subject: Re: how to change the effective user identficator
Message-Id: <230720081036284193%jimsgibson@gmail.com>
In article <g65uv501068@news4.newsguy.com>, szr <szrRE@szromanMO.comVE>
wrote:
> Sherman Pendley wrote:
> > Daneel Yaitskov <rtfm.rtfm.rtfm@gmail.com> writes:
> >
> >> Jürgen Exner wrote:
> >>> [Forwarding to CLPM because CLP is obsolete]
> >>
> >> I don't know what is CLPM.
> >
> > This group - comp.lang.perl.misc. The comp.lang.perl group is
> > obsolete. It was split into sub-groups (c.l.p.announce, c.l.p.misc,
> > c.l.p.modules, etc.) many years ago.
>
> I can't believe any news server actually still carries such old and
> outdated groups.
Usenet.com still carries comp.lang.perl, so believe it!
Keep in mind that one way commercial usenet providers can compete is by
claiming to offer more groups than other providers, and continuing to
carry removed groups is one way to increase their count.
--
Jim Gibson
------------------------------
Date: Wed, 23 Jul 2008 11:40:22 -0700
From: "szr" <szrRE@szromanMO.comVE>
Subject: Re: how to change the effective user identficator
Message-Id: <g67tun03181@news4.newsguy.com>
Jim Gibson wrote:
> In article <g65uv501068@news4.newsguy.com>, szr
> <szrRE@szromanMO.comVE> wrote:
>> Sherman Pendley wrote:
>>> Daneel Yaitskov <rtfm.rtfm.rtfm@gmail.com> writes:
>>>> Jürgen Exner wrote:
>>>>> [Forwarding to CLPM because CLP is obsolete]
>>>>
>>>> I don't know what is CLPM.
>>>
>>> This group - comp.lang.perl.misc. The comp.lang.perl group is
>>> obsolete. It was split into sub-groups (c.l.p.announce, c.l.p.misc,
>>> c.l.p.modules, etc.) many years ago.
>>
>> I can't believe any news server actually still carries such old and
>> outdated groups.
>
> Usenet.com still carries comp.lang.perl, so believe it!
>
> Keep in mind that one way commercial usenet providers can compete is
> by claiming to offer more groups than other providers, and continuing
> to carry removed groups is one way to increase their count.
To me, that's like a car dealership claiming to have more cars than
anyone else, by devoting a section to old junkers that barely run
anymore.
--
szr
------------------------------
Date: Wed, 23 Jul 2008 09:52:22 -0500
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: Mail::IMAPClient usage...
Message-Id: <86y73sd55l.fsf@lifelogs.com>
On Tue, 22 Jul 2008 06:55:08 -0700 (PDT) Yogi <yogeshkagrawal@gmail.com> wrote:
Y> On Jul 22, 6:22 pm, Ted Zlatanov <t...@lifelogs.com> wrote:
>> ...he could also use GMail's IMAP services.
>>
>> GMail IMAP, incidentally, implements a very basic subset of IMAP, but
>> it's probably enough for the OP.
Y> Hi Ted n Rick,
Y> Thanks for your response on this. But even this is not working.
Y> my $pop = new Mail::POP3Client( USER => 'myid',
Y> PASSWORD => 'mypwd',
Y> HOST => "pop.gmail.com:995",
Y> USESSL => 1,
Y> DEBUG => 1
Y> ) || die("Error here $@");
My suggestion is to:
1) enable IMAP on GMail (it's in the account settings, including server name)
2) use Mail::IMAPClient
Ted
------------------------------
Date: Wed, 23 Jul 2008 08:13:43 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: number of maximum decimal places supported with Perl
Message-Id: <g66p7n$2gk3$1@agate.berkeley.edu>
[A complimentary Cc of this posting was sent to
Jack
<jack_posemsky@yahoo.com>], who wrote in article <5046bc0b-e0db-4181-b12f-aabc3dc35ff3@x41g2000hsb.googlegroups.com>:
> Hi there, does anyone know what data type has the most digits of
> precision perl, and what the upper bound (maximum) number of decimal
> places is for that data type ?
Perl can be convinced to use any numeric type supported by a C
compiler. Practically, I expect that nowadays only IEEE floats are
supported by C compilers; this gives 3 possible flavors: 64bit, 80bit,
and 128bit. (Please prove me wrong! ;-)
Wikipedia is your friend,
Ilya
------------------------------
Date: Wed, 23 Jul 2008 05:46:46 -0700 (PDT)
From: Roi <ezraroi@gmail.com>
Subject: PAR packer Error
Message-Id: <15c9f783-9f48-4096-8146-288a673a3c41@a1g2000hsb.googlegroups.com>
Hello,
I am trying to make an exe file from a perl script file. I am using
ActiveState Perl 5.8.6 (Build 811) on Windows.
This is the lcommand that i am running and the error msg:
pp -o sp.exe spdisplaye.pl
Perl lib version (v5.8.6) doesn't match executable version (v5.8.8) at
C:/Perl/
ib/Config.pm line 32.
Compilation failed in require at C:/Perl/lib/DynaLoader.pm line 25.
BEGIN failed--compilation aborted at C:/Perl/lib/DynaLoader.pm line
25.
Compilation failed in require at C:/Perl/site/lib/Compress/Zlib.pm
line 15.
Compilation failed in require at C:/Perl/site/lib/Archive/Zip.pm line
11.
BEGIN failed--compilation aborted at C:/Perl/site/lib/Archive/Zip.pm
line 11.
Compilation failed in require at -e line 406.
C:\Perl\Bin/pp: Failed to extract a parl from
'PAR::StrippedPARL::Static' to fi
e 'parlHk8jbV7.exe' at C:/Perl/site/lib/PAR/Packer.pm line 1149,
<DATA> line 1.
i am using PAR 0.976
i will be happy to find solution for thi problem as i am trying to
solve it for more then 10 hours..
Thanks,
Roi
------------------------------
Date: Wed, 23 Jul 2008 18:16:33 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: PAR packer Error
Message-Id: <hk5kl5-qc2.ln1@osiris.mauzo.dyndns.org>
Quoth Roi <ezraroi@gmail.com>:
> Hello,
> I am trying to make an exe file from a perl script file. I am using
> ActiveState Perl 5.8.6 (Build 811) on Windows.
> This is the lcommand that i am running and the error msg:
>
> pp -o sp.exe spdisplaye.pl
> Perl lib version (v5.8.6) doesn't match executable version (v5.8.8) at
> C:/Perl/
> ib/Config.pm line 32.
What happens if you just run
perl spdisplaye.pl
? It looks to me as though you've messed up your perl installation.
Ben
--
BEGIN{*(=sub{$,=*)=sub{print@_};local($#,$;,$/)=@_;for(keys%{ #ben@morrow.me.uk
$#}){/m/&&next;**=${$#}{$_};/(\w):/&&(&(($#.$_,$;.$+,$/),next);$/==\$*&&&)($;.$
_)}};*_=sub{for(@_){$|=(!$|||$_||&)(q) )));&((q:\:\::,q,,,\$_);$_&&&)("\n")}}}_
$J::u::s::t, $a::n::o::t::h::e::r, $P::e::r::l, $h::a::c::k::e::r, $,
------------------------------
Date: Wed, 23 Jul 2008 08:17:26 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: Perl for calculating an expression.
Message-Id: <g66pem$2goh$1@agate.berkeley.edu>
[A complimentary Cc of this posting was NOT [per weedlist] sent to
Jürgen Exner
<jurgenex@hotmail.com>], who wrote in article <ocdd84h71q15kckvgue9pk7sk4u579vd1e@4ax.com>:
> syang8 <syang8@gmail.com> wrote:
> >Is there any peal script available that I can quickly calculate a
> >string " (3+5)*5/40 " or " 4*7-7*(4+5) " ? There are only the digits
> >and +,-,*,/ and () available in the string. Thank you!
>
> Is quick and dirty good enough? Then just use eval().
>
> Otherwise writing a simple parser and interpreter for such a tiny
> language is a favourite second semester excercise.
Here are my aliases (4dos and tcsh):
>alias pprint
pprint -e "print {STDOUT} %&"
>alias _pprint
perl -wle "sub atan($) {atan2 shift, 1} sub tan($) {sin($_[0])/cos($_[0])} sub pi () {atan2 0, -1} sub e() {exp 1} sub h() {'6.62607e-34'} sub eV() {'1.6021765e-19'} sub G() {6.674e-11} sub N() {6.022142e23} sub c() {299792458} sub R() {8.314472} sub k() {R/N} $, = q(, ); "
->alias pprint
perl -wle '$, = q(, ); print(!:1*)'
Hope this helps,
Ilya
------------------------------
Date: Wed, 23 Jul 2008 12:40:19 +0200
From: Leon Timmermans <fawaka@gmail.com>
Subject: Re: Perl for calculating an expression.
Message-Id: <d31b2$48870a93$89e0e08f$28107@news2.tudelft.nl>
On Tue, 22 Jul 2008 21:36:26 -0700, syang8 wrote:
> Is there any peal script available that I can quickly calculate a string
> " (3+5)*5/40 " or " 4*7-7*(4+5) " ? There are only the digits and
> +,-,*,/ and () available in the string. Thank you!
>
> -Steve
Look up Dijkstra's shunting yard algorithm. It's quite easy to implement.
Leon Timmermans
------------------------------
Date: 23 Jul 2008 14:06:10 GMT
From: Glenn Jackman <glennj@ncf.ca>
Subject: Re: Perl for calculating an expression.
Message-Id: <slrng8eemj.c3r.glennj@smeagol.ncf.ca>
At 2008-07-23 12:36AM, "syang8" wrote:
> Is there any peal script available that I can quickly calculate a
> string " (3+5)*5/40 " or " 4*7-7*(4+5) " ? There are only the digits
> and +,-,*,/ and () available in the string. Thank you!
$str =~ m{^([\s\d()/*+-]+)$} and $result = eval $1;
This does not check that your expression is "well formed" (e.g. $str="1+")
--
Glenn Jackman
Write a wise saying and your name will live forever. -- Anonymous
------------------------------
Date: Wed, 23 Jul 2008 14:50:00 GMT
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Perl for calculating an expression.
Message-Id: <83he84p2egn1018k7e717mlrbrogdiukl6@4ax.com>
Glenn Jackman <glennj@ncf.ca> wrote:
>At 2008-07-23 12:36AM, "syang8" wrote:
>> Is there any peal script available that I can quickly calculate a
>> string " (3+5)*5/40 " or " 4*7-7*(4+5) " ? There are only the digits
>> and +,-,*,/ and () available in the string. Thank you!
>
> $str =~ m{^([\s\d()/*+-]+)$} and $result = eval $1;
>
>This does not check that your expression is "well formed" (e.g. $str="1+")
Yes, it does:
If there is a syntax error or runtime error, [...],
an undefined value is returned by "eval", [...]
The code doesn't doesn't do any error handling, but that's a different
animal.
jue
------------------------------
Date: Wed, 23 Jul 2008 19:57:39 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Slow GC before program termination (was: C linked lists in Perl)
Message-Id: <slrng8es8k.v16.hjp-usenet2@hrunkner.hjp.at>
On 2008-07-22 18:15, Joost Diepenmaat <joost@zeekat.nl> wrote:
> "Peter J. Holzer" <hjp-usenet2@hjp.at> writes:
>> That program doesn't demonstrate that it is "relatively slow". You would
>> have to compare it to something else relative to which it is slow.
>
> True. I don't have a good comparison ready at the moment, and I think
> I confused the refcounting GC with the "general GC" at END time (which
> *is* a lot slower than the refcounting GC). Please ignore it.
Do you know why the END time GC is so slow? I only notice it when my
script needs more VM than my machine has RAM, so I assumed that it was
just the threshing which occurs when VM is accessed in mostly random
order. I didn't think that the GC at that time is somehow different from
GC which occurs when a variable goes out of scope.
hp
------------------------------
Date: Wed, 23 Jul 2008 19:40:01 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Slow GC before program termination (was: C linked lists in Perl)
Message-Id: <1hakl5-id5.ln1@osiris.mauzo.dyndns.org>
Quoth "Peter J. Holzer" <hjp-usenet2@hjp.at>:
> On 2008-07-22 18:15, Joost Diepenmaat <joost@zeekat.nl> wrote:
> > "Peter J. Holzer" <hjp-usenet2@hjp.at> writes:
> >> That program doesn't demonstrate that it is "relatively slow". You would
> >> have to compare it to something else relative to which it is slow.
> >
> > True. I don't have a good comparison ready at the moment, and I think
> > I confused the refcounting GC with the "general GC" at END time (which
> > *is* a lot slower than the refcounting GC). Please ignore it.
>
> Do you know why the END time GC is so slow?
Basically because perl has to make sure it collects *everything*,
including things with circular references. Once-upon-a-time, perl used
to just _exit and let the OS clean up; since perl has been ported to
OSen which don't (Win32, I'm looking at you here) and since Perl now
supports DESTROY methods, it has to clean everything up itself. However,
although perl guarentees to call DESTROY methods when the process exits,
it *doesn't* guarentee to do so in a sane order, which is often a source
of bugs.
Ben
--
Musica Dei donum optimi, trahit homines, trahit deos. |
Musica truces mollit animos, tristesque mentes erigit. | ben@morrow.me.uk
Musica vel ipsas arbores et horridas movet feras. |
------------------------------
Date: Wed, 23 Jul 2008 21:05:00 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Undefined behaviour (was: C linked lists in Perl)
Message-Id: <slrng8f06v.v16.hjp-usenet2@hrunkner.hjp.at>
On 2008-07-22 18:07, Joost Diepenmaat <joost@zeekat.nl> wrote:
> "szr" <szrRE@szromanMO.comVE> writes:
>
>>> $tail = ($tail->[1] = [$_]);
>> ^^^^^^^^^^^^^^^^^^^^^
>>
>> Is it any surprise that it segfaults when you're using a construct with
>> undefined behavior?
>
> how is that behaviour undefined?
perldoc perlop:
Note that just as in C, Perl doesn’t define when the variable is
incremented or decremented. You just know it will be done sometime
before or after the value is returned. This also means that modifying a
variable twice in the same statement will lead to undefined behaviour.
AFAIK this is the only place in the perl doc which refers to "undefined
behaviour".
However, this is very unclear. Unlike C, which has a general rule which
defines when modifying an lvalue yields defined behaviour and when it
yields undefined behaviour, Perl doesn't. We don't even know if that
paragraph refers only to the ++ and -- operators or to all assignment
operators. Also in C, "undefined behaviour" really means "anything can
happen, including a crash, the compiler refusing to compile the program,
or a sudden affluence of nasal demons. The above paragraph (as well as
the next sentence "Perl will not guarantee what the result of the above
statements is.") suggest that only the order of evaluation is undefined.
By C rules,
$tail = ($tail->[1] = [$_]);
is undefined, because an lvalue which is modified between to sequence
points may be read only to determine its new value. In the above
statement, $tail is modified ($tail = ...) and also read ($tail->[1]),
but not to determine its new value, but to determine the location to
which [$_] will be assigned. (Although that's a bit of an edge case - I
think one could argue that $tail is needed to compute $tail->[1] in turn
is needed to determine the value of ($tail->[1] = [$_]) which is then
assigned to $tail. But then, because of autovivification, assigning to
$tail->[1] may modify $tail, so $tail would be modified twice between
two sequence points, which is also forbidden, so this would again be
undefined).
But I don't think C rules apply to Perl. The languages are too
different, and the Perl docs should be fixed to spell out the rules for
Perl.
Basically I see three possibilities:
1) Eliminate "undefined behaviour" completely: Work out how expressions
are evaluated by current perl, document it and specify it as the way
it should be.
2) Specify some rules for expression evaluation, but leave some details
explicitely unspecified. For example, one could specify that any
subexpression of an operator is completely evaluated before the
operator, not specify the order in which the subexpressions are
evaluated.
3) Stick with C's idea of sequence points and document where they occur
and what counts as "modifying an lvalue".
Personally, I'm in favour of 2, but right now I couldn't come up with a
consistent set of rules which explains why
perl -e '$i = 5; $x = ++ $i + $i ++; print "$x\n" '
prints 13.
hp
------------------------------
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:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#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 1743
***************************************
