[32772] in Perl-Users-Digest
Perl-Users Digest, Issue: 4037 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Sep 20 20:37:02 2013
Date: Thu, 19 Sep 2013 08:09:04 -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 Thu, 19 Sep 2013 Volume: 11 Number: 4037
Today's topics:
automatic number <-> string conversions <rweikusat@mobileactivedefense.com>
Re: automatic number <-> string conversions <rweikusat@mobileactivedefense.com>
Re: automatic number <-> string conversions <derykus@gmail.com>
Re: automatic number <-> string conversions <ben@morrow.me.uk>
Re: automatic number <-> string conversions <derykus@gmail.com>
Re: automatic number <-> string conversions <rweikusat@mobileactivedefense.com>
Re: automatic number <-> string conversions <ben@morrow.me.uk>
Re: automatic number <-> string conversions <ben@morrow.me.uk>
Re: automatic number <-> string conversions <derykus@gmail.com>
Re: automatic number <-> string conversions <hjp-usenet3@hjp.at>
Re: automatic number <-> string conversions <ben@morrow.me.uk>
Re: automatic number <-> string conversions <rweikusat@mobileactivedefense.com>
Re: automatic number <-> string conversions <ben@morrow.me.uk>
Re: Return values of boolean operators <rweikusat@mobileactivedefense.com>
Re: The old-fashioned guestbook <tuxedo@mailinator.com>
Re: The old-fashioned guestbook <uri@stemsystems.com>
Re: The old-fashioned guestbook <tuxedo@mailinator.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 18 Sep 2013 10:43:51 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: automatic number <-> string conversions
Message-Id: <87ioxyv50o.fsf@sable.mobileactivedefense.com>
Coming to think of this, I'd agree that automatically converting a
non-numerical string to a number with value zero is rarely useful and
likely to lead to unpleasnt surprises, eg
[rw@sable]/tmp#perl -e 'print "David" == "Nick", "\n"'
1
(although this could be referred to 'deeper insight')
That's consistent with how atoi/ strtol would behave,
-----------
#include <stdlib.h>
#include <stdio.h>
int main(void)
{
printf("%d\n", atoi("Salad") == atoi("Steak"));
return 0;
}
----------
but that's more likely to be an 1970s implemenetation shortcut than a
conscious semantic choice and in any case, someone who knows Perl won't
necessarily/ shouldn't need to know C as well.
OTOH, I think the so-called 'undefined value', at least insofar it is
used as default value of an uninitialized variable, should be an
exception here: A variable with 'no value' should behave as if it had
some 'neutral value' for the context it is used in: Explicit
initialization should only be necessary when something other like than
this 'neutral value' is needed. Forcing people to write
my $a;
$a = 0;
print($a + 1);
instead of
my $a
print($a + 1);
just clutters the code with a lot of 'self-evident' statements.
------------------------------
Date: Wed, 18 Sep 2013 10:51:13 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: automatic number <-> string conversions
Message-Id: <87eh8mv4oe.fsf@sable.mobileactivedefense.com>
Rainer Weikusat <rweikusat@mobileactivedefense.com> writes:
[...]
> [rw@sable]/tmp#perl -e 'print "David" == "Nick", "\n"'
> 1
>
> (although this could be referred to 'deeper insight')
Silly joke I can resist ATM: This works even nicer in German because
"beides Nullen" (both zeroes) is colloquial for "guys who can't get
anything done because it is beyond them" :->
------------------------------
Date: Wed, 18 Sep 2013 03:29:02 -0700
From: Charles DeRykus <derykus@gmail.com>
Subject: Re: automatic number <-> string conversions
Message-Id: <l1bv9p$qiu$1@speranza.aioe.org>
On 9/18/2013 2:51 AM, Rainer Weikusat wrote:
> Rainer Weikusat <rweikusat@mobileactivedefense.com> writes:
>
> [...]
>
>> [rw@sable]/tmp#perl -e 'print "David" == "Nick", "\n"'
>> 1
>>
>> (although this could be referred to 'deeper insight')
>
> Silly joke I can resist ATM: This works even nicer in German because
> "beides Nullen" (both zeroes) is colloquial for "guys who can't get
> anything done because it is beyond them" :->
>
At least perl warns when "beides Nullen" is "beyond the pale":
perl -wE 'print "David" == "Nick"'
Argument "Nick" isn't numeric in numeric eq (==) at -e line 1.
...
--
Charles DeRykus
------------------------------
Date: Wed, 18 Sep 2013 17:55:45 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: automatic number <-> string conversions
Message-Id: <hh2pga-161.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mobileactivedefense.com>:
> Coming to think of this, I'd agree that automatically converting a
> non-numerical string to a number with value zero is rarely useful and
> likely to lead to unpleasnt surprises, eg
>
> [rw@sable]/tmp#perl -e 'print "David" == "Nick", "\n"'
> 1
>
> (although this could be referred to 'deeper insight')
>
> That's consistent with how atoi/ strtol would behave,
>
> -----------
> #include <stdlib.h>
> #include <stdio.h>
>
> int main(void)
> {
> printf("%d\n", atoi("Salad") == atoi("Steak"));
> return 0;
> }
> ----------
>
> but that's more likely to be an 1970s implemenetation shortcut than a
> conscious semantic choice and in any case, someone who knows Perl won't
> necessarily/ shouldn't need to know C as well.
atoi has no choice: it has to return some int or other to signal
'invalid input', and it's obviously going to return the same one for
different invalid inputs. Since int doesn't have a NaN value, the return
values are going to be equal.
> OTOH, I think the so-called 'undefined value', at least insofar it is
> used as default value of an uninitialized variable, should be an
> exception here: A variable with 'no value' should behave as if it had
> some 'neutral value' for the context it is used in: Explicit
> initialization should only be necessary when something other like than
> this 'neutral value' is needed.
I agree. Uninit value warnings were much more useful in the pre-strict
days when an unexpected undef often meant you had autocreated a variable
without meaning to. These days "uninitiailisized" is the warning
category I turn off most often (the next is probably "exiting").
Ben
------------------------------
Date: Wed, 18 Sep 2013 15:11:58 -0700
From: Charles DeRykus <derykus@gmail.com>
Subject: Re: automatic number <-> string conversions
Message-Id: <l1d8fs$n31$1@speranza.aioe.org>
On 9/18/2013 9:55 AM, Ben Morrow wrote:
>
> Quoth Rainer Weikusat <rweikusat@mobileactivedefense.com>:
> ...
>>
>> but that's more likely to be an 1970s implemenetation shortcut than a
>> conscious semantic choice and in any case, someone who knows Perl won't
>> necessarily/ shouldn't need to know C as well.
>
> atoi has no choice: it has to return some int or other to signal
> 'invalid input', and it's obviously going to return the same one for
> different invalid inputs. Since int doesn't have a NaN value, the return
> values are going to be equal.
>
>> OTOH, I think the so-called 'undefined value', at least insofar it is
>> used as default value of an uninitialized variable, should be an
>> exception here: A variable with 'no value' should behave as if it had
>> some 'neutral value' for the context it is used in: Explicit
>> initialization should only be necessary when something other like than
>> this 'neutral value' is needed.
>
> I agree. Uninit value warnings were much more useful in the pre-strict
> days when an unexpected undef often meant you had autocreated a variable
> without meaning to. These days "uninitiailisized" is the warning
> category I turn off most often (the next is probably "exiting").
>
But, IIUC, I'm not sure how Perl could thread the twisty-turny maze to
warn sanely but not annoyingly.
Sensibly in lvalue settings, it doesn't: 'my $x; say ++$x;'
or: 'my $x; $x .= "foo";
But, most of the time, it seems to me there's more likely a need for a
warning than not, eg,
'my $x; my $y = "Alice hates $x...and the Red Queen;"
If there were no warning because "nothing other than its neutral value
is needed for the context it is used in", it'd fail to alert the author
to expressions that had changed in havoc-wreaking ways computationally
(or semantically).
--
Charles DeRykus
------------------------------
Date: Thu, 19 Sep 2013 01:35:02 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: automatic number <-> string conversions
Message-Id: <87txhhwsw9.fsf@sable.mobileactivedefense.com>
Charles DeRykus <derykus@gmail.com> writes:
> On 9/18/2013 9:55 AM, Ben Morrow wrote:
>> Quoth Rainer Weikusat <rweikusat@mobileactivedefense.com>:
[...]
>>> OTOH, I think the so-called 'undefined value', at least insofar it is
>>> used as default value of an uninitialized variable, should be an
>>> exception here: A variable with 'no value' should behave as if it had
>>> some 'neutral value' for the context it is used in: Explicit
>>> initialization should only be necessary when something other like than
>>> this 'neutral value' is needed.
>>
>> I agree. Uninit value warnings were much more useful in the pre-strict
>> days when an unexpected undef often meant you had autocreated a variable
>> without meaning to. These days "uninitiailisized" is the warning
>> category I turn off most often (the next is probably "exiting").
>>
>
> But, IIUC, I'm not sure how Perl could thread the twisty-turny maze to
> warn sanely but not annoyingly.
>
> Sensibly in lvalue settings, it doesn't: 'my $x; say ++$x;'
> or: 'my $x; $x .= "foo";
>
> But, most of the time, it seems to me there's more likely a need for a
> warning than not, eg,
>
> 'my $x; my $y = "Alice hates $x...and the Red Queen;"
>
> If there were no warning because "nothing other than its neutral value
> is needed for the context it is used in", it'd fail to alert the
> author to expressions that had changed in havoc-wreaking ways
> computationally (or semantically).
Simple. Warn if a string without leading digits is implicitly converted
to a 0. Don't warn if 'an undefined value' is used as if somebody
thought he wasn't accessing some a C 'stack-allocated object' which was
left unitialized for performance reason because that's totally
ridicolous for perl, anyway, and not true. Not everything which has
always worked in this way since 1973 for reasons we've long stopped to
care about has to continue to work in this way. That's going to be a
good idea in certain cases and a bad idea in certain other cases and
*for me*, the benefits outweigh the drawbacks.
------------------------------
Date: Thu, 19 Sep 2013 02:00:06 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: automatic number <-> string conversions
Message-Id: <mtupga-3u7.ln1@anubis.morrow.me.uk>
Quoth Charles DeRykus <derykus@gmail.com>:
> On 9/18/2013 9:55 AM, Ben Morrow wrote:
> >
> > I agree. Uninit value warnings were much more useful in the pre-strict
> > days when an unexpected undef often meant you had autocreated a variable
> > without meaning to. These days "uninitiailisized" is the warning
> > category I turn off most often (the next is probably "exiting").
>
> But, IIUC, I'm not sure how Perl could thread the twisty-turny maze to
> warn sanely but not annoyingly.
IMHO with properly scoped variables an undef is no more likely to be a
mistake than any other value. IME undef warnings cause more problems (in
terms of unnecessary code to work around them) than they solve. A simple
example would be something like this:
my $verb = $conf{verbose} + $ENV{FOO_VERBOSE} + $opt{v};
where silently treating a nonexistent setting as 0 is the right thing to
do. With undef warnings turned on that line of code has to become a good
bit more complex, to no real advantage.
> Sensibly in lvalue settings, it doesn't: 'my $x; say ++$x;'
> or: 'my $x; $x .= "foo";
>
> But, most of the time, it seems to me there's more likely a need for a
> warning than not, eg,
>
> 'my $x; my $y = "Alice hates $x...and the Red Queen;"
>
> If there were no warning because "nothing other than its neutral value
> is needed for the context it is used in", it'd fail to alert the author
> to expressions that had changed in havoc-wreaking ways computationally
> (or semantically).
In that particular case an empty string makes no more sense than an
undef, but an empty string won't warn. In the general case, there are a
great many possible wrong values in any given situation, and undef is no
more likely to be one of them than anything else.
Ben
------------------------------
Date: Thu, 19 Sep 2013 02:21:24 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: automatic number <-> string conversions
Message-Id: <k50qga-2j8.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mobileactivedefense.com>:
>
[undef warnings]
> Simple. Warn if a string without leading digits is implicitly converted
> to a 0. Don't warn if 'an undefined value' is used as if somebody
> thought he wasn't accessing some a C 'stack-allocated object' which was
> left unitialized for performance reason because that's totally
> ridicolous for perl, anyway, and not true.
I'm pretty certain that wasn't the reason. The warning was added in perl
2 (and goodness me, perl was a lot simpler in those days!); the only
comments about it still preserved in the perl repo are this paragraph in
the manpage:
.B \-w
prints warnings about identifiers that are mentioned only once, and
scalar variables that are used before being set.
Also warns about redefined subroutines, and references to undefined
subroutines and filehandles.
and this comment from the git commit message for perl-2.0, which I
believe was taken from a release announcement of some sort:
* Warnings are now available (with -w) on use of uninitialized
variables and on identifiers that are mentioned only once, and on
reference to various undefined things.
Both of these (and the fact that the message is about an 'uninitialized'
rather than an 'undefined' value) lead me to believe that the intention
was to catch variables created by mistake (through typos and such)
rather than because of any illusions about Perl behaving like C.
Ben
------------------------------
Date: Wed, 18 Sep 2013 23:24:14 -0700
From: Charles DeRykus <derykus@gmail.com>
Subject: Re: automatic number <-> string conversions
Message-Id: <l1e5ar$kgg$1@speranza.aioe.org>
On 9/18/2013 6:00 PM, Ben Morrow wrote:
>
> Quoth Charles DeRykus <derykus@gmail.com>:
>> On 9/18/2013 9:55 AM, Ben Morrow wrote:
...
>
> IMHO with properly scoped variables an undef is no more likely to be a
> mistake than any other value. IME undef warnings cause more problems (in
> terms of unnecessary code to work around them) than they solve. A simple
> example would be something like this:
>
> my $verb = $conf{verbose} + $ENV{FOO_VERBOSE} + $opt{v};
>
> where silently treating a nonexistent setting as 0 is the right thing to
> do. With undef warnings turned on that line of code has to become a good
> bit more complex, to no real advantage.
Maybe it's a personal bias bordering on an OCD affliction, but I'd
rather see that as: my $verb = ... + ($ENV{FOO_VERBOSE} // 0) + ...
IMO not appallingly tedious and documenting clearly what's going on.
>
>> Sensibly in lvalue settings, it doesn't: 'my $x; say ++$x;'
>> or: 'my $x; $x .= "foo";
>>
>> But, most of the time, it seems to me there's more likely a need for a
>> warning than not, eg,
>>
>> 'my $x; my $y = "Alice hates $x...and the Red Queen;"
>>
>> If there were no warning because "nothing other than its neutral value
>> is needed for the context it is used in", it'd fail to alert the author
>> to expressions that had changed in havoc-wreaking ways computationally
>> (or semantically).
>
> In that particular case an empty string makes no more sense than an
> undef, but an empty string won't warn. In the general case, there are a
> great many possible wrong values in any given situation, and undef is no
> more likely to be one of them than anything else.
>
Right. But, IMO, particularly in early development, you're more likely
to forget to initialize and -w can really help. Then you graduate to
more refined types of mayhem and no one can help you.
--
Charles DeRykus
------------------------------
Date: Thu, 19 Sep 2013 12:29:10 +0200
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: automatic number <-> string conversions
Message-Id: <slrnl3lkfm.a71.hjp-usenet3@hrunkner.hjp.at>
On 2013-09-19 01:00, Ben Morrow <ben@morrow.me.uk> wrote:
>
> Quoth Charles DeRykus <derykus@gmail.com>:
>> On 9/18/2013 9:55 AM, Ben Morrow wrote:
>> >
>> > I agree. Uninit value warnings were much more useful in the pre-strict
>> > days when an unexpected undef often meant you had autocreated a variable
>> > without meaning to. These days "uninitiailisized" is the warning
>> > category I turn off most often (the next is probably "exiting").
>>
>> But, IIUC, I'm not sure how Perl could thread the twisty-turny maze to
>> warn sanely but not annoyingly.
>
> IMHO with properly scoped variables an undef is no more likely to be a
> mistake than any other value.
I disagree with that estimation. Undef is much more likely to be a
mistake than any other value because it *means* "no value". So when I
expect a numerical value, 23 may or may not be a mistake, but undef is
certain to be one - because I expect a numerical value and undef isn't
that.
Of course that depends on your coding style. If you treat undef like 0
or an empty string, the warning is just annoying and not helpful at all.
But the way I code, an undef in a place where I didn't expect it almost
always means that there is an error in my logic.
That said, uninitialized is also the warning category I turn off most
often (and I probably mistype it just as often as you ;-)), although
usually in a very tight scope and often around debug output.
Especially for debug output a way to replace it with something else than
"" would be handy, for example something like this:
my $foo = "bla";
my $bar;
{
local $^@ = "(undef)";
say "foo=$foo bar=$bar"
}
could print
foo=bla bar=(undef)
> IME undef warnings cause more problems (in
> terms of unnecessary code to work around them) than they solve. A simple
> example would be something like this:
>
> my $verb = $conf{verbose} + $ENV{FOO_VERBOSE} + $opt{v};
I think I would write that as
my $verb = $conf{verbose} // $ENV{FOO_VERBOSE} // $opt{v};
(or probably the other way around).
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | 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: Thu, 19 Sep 2013 14:06:43 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: automatic number <-> string conversions
Message-Id: <3g9rga-s6h.ln1@anubis.morrow.me.uk>
Quoth Charles DeRykus <derykus@gmail.com>:
> On 9/18/2013 6:00 PM, Ben Morrow wrote:
> >
> > IMHO with properly scoped variables an undef is no more likely to be a
> > mistake than any other value. IME undef warnings cause more problems (in
> > terms of unnecessary code to work around them) than they solve. A simple
> > example would be something like this:
> >
> > my $verb = $conf{verbose} + $ENV{FOO_VERBOSE} + $opt{v};
> >
> > where silently treating a nonexistent setting as 0 is the right thing to
> > do. With undef warnings turned on that line of code has to become a good
> > bit more complex, to no real advantage.
>
> Maybe it's a personal bias bordering on an OCD affliction, but I'd
> rather see that as: my $verb = ... + ($ENV{FOO_VERBOSE} // 0) + ...
If I were Rainer I would accuse you of having been brainwashed by the
Perl Conspiracy... :)
> >> But, most of the time, it seems to me there's more likely a need for a
> >> warning than not, eg,
> >>
> >> 'my $x; my $y = "Alice hates $x...and the Red Queen;"
> >>
> >> If there were no warning because "nothing other than its neutral value
> >> is needed for the context it is used in", it'd fail to alert the author
> >> to expressions that had changed in havoc-wreaking ways computationally
> >> (or semantically).
> >
> > In that particular case an empty string makes no more sense than an
> > undef, but an empty string won't warn. In the general case, there are a
> > great many possible wrong values in any given situation, and undef is no
> > more likely to be one of them than anything else.
>
> Right. But, IMO, particularly in early development, you're more likely
> to forget to initialize and -w can really help. Then you graduate to
> more refined types of mayhem and no one can help you.
Maybe it's to do with coding style; I generally consider a variable
declared but not initialised to be a red flag anyway (because it could
probably have been scoped tighter).
Ben
------------------------------
Date: Thu, 19 Sep 2013 14:18:37 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: automatic number <-> string conversions
Message-Id: <874n9h0x1u.fsf@sable.mobileactivedefense.com>
"Peter J. Holzer" <hjp-usenet3@hjp.at> writes:
> On 2013-09-19 01:00, Ben Morrow <ben@morrow.me.uk> wrote:
>>
>> Quoth Charles DeRykus <derykus@gmail.com>:
>>> On 9/18/2013 9:55 AM, Ben Morrow wrote:
>>> >
>>> > I agree. Uninit value warnings were much more useful in the pre-strict
>>> > days when an unexpected undef often meant you had autocreated a variable
>>> > without meaning to. These days "uninitiailisized" is the warning
>>> > category I turn off most often (the next is probably "exiting").
>>>
>>> But, IIUC, I'm not sure how Perl could thread the twisty-turny maze to
>>> warn sanely but not annoyingly.
>>
>> IMHO with properly scoped variables an undef is no more likely to be a
>> mistake than any other value.
>
> I disagree with that estimation. Undef is much more likely to be a
> mistake than any other value because it *means* "no value".
[...]
> Of course that depends on your coding style. If you treat undef like 0
> or an empty string, the warning is just annoying and not helpful at
> all.
If someone treats Perl like C (or C++ or Java, FWIW) with respect to not
otherwise initialized my variables, that is, assigning values to them
even although automatic conversion of 'undef' to a suitable type would
result in the same value, then, 'undef' being used instead of some
'defined value' should rarely[*] ever happen. But Perl isn't C and it
doesn't suffer from the 'bad habit' of making storage locations
available to code while leaking whatever value the most recent user of
this storage location happened to leave there: Variables created with my
are not uninitialized and I consider the fact that they will 'behave
themselves' according to the ways they're used in a feature (and a very
convenient one at that).
[*] There's still the issue that some builtin functions return undef as
'false value' and that using 0 and 1 in order to mean 'true' and 'false'
can be convenient because it is possible to do ordinary arithmetic with
'boolean values', eg (contrived example)
my $results;
$result = call_a();
$result |= call_b();
$result |= call_c();
print("Something worked!\n") if $result;
------------------------------
Date: Thu, 19 Sep 2013 14:26:10 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: automatic number <-> string conversions
Message-Id: <ikarga-2hh.ln1@anubis.morrow.me.uk>
Quoth "Peter J. Holzer" <hjp-usenet3@hjp.at>:
> On 2013-09-19 01:00, Ben Morrow <ben@morrow.me.uk> wrote:
> >
> > IMHO with properly scoped variables an undef is no more likely to be a
> > mistake than any other value.
>
> I disagree with that estimation. Undef is much more likely to be a
> mistake than any other value because it *means* "no value". So when I
> expect a numerical value, 23 may or may not be a mistake, but undef is
> certain to be one - because I expect a numerical value and undef isn't
> that.
>
> Of course that depends on your coding style. If you treat undef like 0
> or an empty string, the warning is just annoying and not helpful at all.
> But the way I code, an undef in a place where I didn't expect it almost
> always means that there is an error in my logic.
Yes, I think it depends on coding style, and on what one considers
'clean'. However, there are lots of situations where undefs can't be
avoided, and yet ideally should be treatable as a string: nonexistent
hash elements; sub arguments which weren't supplied; the return value of
'reftype' and 'blessed' on a non-ref; and so on.
> That said, uninitialized is also the warning category I turn off most
> often (and I probably mistype it just as often as you ;-)), although
> usually in a very tight scope and often around debug output.
>
> Especially for debug output a way to replace it with something else than
> "" would be handy, for example something like this:
>
>
> my $foo = "bla";
> my $bar;
> {
> local $^@ = "(undef)";
> say "foo=$foo bar=$bar"
> }
>
> could print
>
> foo=bla bar=(undef)
use Data::Dump qw/pp/;
though it doesn't interpolate as nicely. I often find myself writing
'sayf' and 'warnf' subs.
> > IME undef warnings cause more problems (in
> > terms of unnecessary code to work around them) than they solve. A simple
> > example would be something like this:
> >
> > my $verb = $conf{verbose} + $ENV{FOO_VERBOSE} + $opt{v};
>
> I think I would write that as
>
> my $verb = $conf{verbose} // $ENV{FOO_VERBOSE} // $opt{v};
>
> (or probably the other way around).
That was meant to be additive: that is, extra -v options on the command-
line increase the verbosity over that specified in the config file. If
it was simply boolean then // (or probably ||, which doesn't mind undef
either, and is more obviously boolean) would be a better choice.
Ben
------------------------------
Date: Wed, 18 Sep 2013 10:17:15 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Return values of boolean operators
Message-Id: <87mwnav690.fsf@sable.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Rainer Weikusat <rweikusat@mobileactivedefense.com>:
>> Ben Morrow <ben@morrow.me.uk> writes:
>> > Quoth Peter Makholm <peter@makholm.net>:
>> >> tmcd@panix.com (Tim McDaniel) writes:
>> >> > OK, which man page is it that has documentation of the return values
>> >> > of boolean operators?
[...]
>> >> Basically it returns a dualvar, not quite unlike what is returned by
>> >>
>> >> Scalar::Util::dualvar(0,"")
>> >
>> > Exactly the same, in fact, except for PL_sv_no (the internal name of the
>> > standard 'false' value) being a readonly constant. That means that this
>> >
>> > my $x = \!1;
>> > $$x = 1;
>> >
>> > will fail, whereas a ref to a dualvar can be modified. They are
>> > otherwise identical, as you can see with Devel::Peek.
>>
>> At least for me, they're not. Dumping a false value results in
>>
>> SV = PVNV(0x83c2188) at 0x83fb448
>> REFCNT = 1
>> FLAGS = (IOK,NOK,POK,pIOK,pNOK,pPOK)
>> IV = 0
>> NV = 0
>> PV = 0x83fe968 ""\0
>> CUR = 0
>> LEN = 4
>
> That's not PL_sv_no: sv_no is immortal, so it has a very high refcount,
> and readonly. It's probably a copy of sv_no: it's got an empty string
> part, and zero IV and NV parts.
Yes.
>> while a dualvar constructed in this kind yields
>>
>> SV = PVMG(0x840fad8) at 0x8400868
>
> I've no idea how you got a PVMG out of dualvar, but I think you must
> have assigned the result to a variable which had already been used for
> something else. The normal return value of dualvar is a PVNV.
This turned out to be a side-effect of using the Perl debugger
interactively.
>> REFCNT = 1
>> FLAGS = (IOK,POK,pIOK,pPOK)
>> IV = 0
>> NV = 0
>> PV = 0x83d6618 ""\0
>> CUR = 0
>> LEN = 4
>
> This SV is otherwise identical to the one above: it isn't NOK yet, but
> that's just because it hasn't been evaluated in a NV context. The
> difference between IOK and NOK is not visible from Perl.
That would make it a SV which is equivalent for certain purposes but not
for others (trivially, SvNOK will indicate 'it is one' for the 'false'
value but not for the dualvar, at least according to the documentation).
------------------------------
Date: Wed, 18 Sep 2013 09:46:41 +0200
From: Tuxedo <tuxedo@mailinator.com>
Subject: Re: The old-fashioned guestbook
Message-Id: <l1blp2$4qa$1@news.albasani.net>
Scott Bryce wrote:
> On 9/16/2013 10:42 AM, Tuxedo wrote:
> > I'm looking for a guestbook application, ideally in Perl, free or at
> > a cost.
>
>
> Are the NMS scripts still considered secure? According to the site, the
> last update to the guestbook script was made Feb 2006.
>
As far as I can remember, Matt Wright's scripts were frequently reported as
insecure, I guess because the archive was one of the first of its kind.
Nevertheless, I will check to see if it's still current
http://www.scriptarchive.com/download.cgi?s=guestbook&c=txt&f=README
http://www.scriptarchive.com/readme/guestbook.html#bugs
"Created 4/21/95"
It qualifies for old-fashioned, although I have a feeling this script is
not going to be of much use.
Tuxedo
------------------------------
Date: Wed, 18 Sep 2013 11:34:58 -0400
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: The old-fashioned guestbook
Message-Id: <87vc1yuorh.fsf@stemsystems.com>
>>>>> "T" == Tuxedo <tuxedo@mailinator.com> writes:
T> Scott Bryce wrote:
>> On 9/16/2013 10:42 AM, Tuxedo wrote:
>> > I'm looking for a guestbook application, ideally in Perl, free or at
>> > a cost.
>>
>>
>> Are the NMS scripts still considered secure? According to the site, the
>> last update to the guestbook script was made Feb 2006.
>>
T> As far as I can remember, Matt Wright's scripts were frequently
T> reported as insecure, I guess because the archive was one of the
T> first of its kind. Nevertheless, I will check to see if it's still
T> current
T> http://www.scriptarchive.com/download.cgi?s=guestbook&c=txt&f=README
T> http://www.scriptarchive.com/readme/guestbook.html#bugs
T> It qualifies for old-fashioned, although I have a feeling this script is
T> not going to be of much use.
you are confusing the original matt's scripts with the NMS
collection. NMS (originally named Not Matt's Scripts) are complete
rewrites using cgi.pm and not full of holes. they are drop in
replacements for matt's piles of stinking turd scripts. even matt has
said to use NMS over his old code. and yet there are still matt's stuff
running out there due to the name and search engine hits.
uri
------------------------------
Date: Wed, 18 Sep 2013 21:36:17 +0200
From: Tuxedo <tuxedo@mailinator.com>
Subject: Re: The old-fashioned guestbook
Message-Id: <l1cvbh$pej$1@news.albasani.net>
Uri Guttman wrote:
[...]
> you are confusing the original matt's scripts with the NMS
> collection. NMS (originally named Not Matt's Scripts) are complete
> rewrites using cgi.pm and not full of holes. they are drop in
> replacements for matt's piles of stinking turd scripts. even matt has
> said to use NMS over his old code. and yet there are still matt's stuff
> running out there due to the name and search engine hits.
>
> uri
Many thanks for the clarification!
Tuxedo
------------------------------
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 4037
***************************************
