Subroutines and '&'
Bill H
&something;
sub something
{
return;
}
But I see in the perlfaq that the '&' isnt used. Is there any reason I
should / should't be using the '&' or does it just not make a
difference?
Bill H
Gunnar Hjalmarsson
Sherm Pendley
It *does* make a difference - if you don't know or understand what that
difference is, or you don't specifically want the behavior specified by
the &, you shouldn't use it.
You can read about this in "perldoc perlsub".
sherm--
--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net
~greg
"Bill H" <bi...@ts1000.us> wrote in message news:1186485205....@w3g2000hsg.googlegroups.com...
How old are you? :)
The reason that I ask is that I don't think that that syntax
has been required for a very long time. (Not since perl v5 I think).
It is still required,
but only when dealing with references (I think)
~~~
use strict;
use warnings;
# ;)
sub something
{
print "something\n";
}
my $something = \&something;
$something->();
__END__
Randal L. Schwartz
Sherm> It *does* make a difference - if you don't know or understand what that
Sherm> difference is, or you don't specifically want the behavior specified by
Sherm> the &, you shouldn't use it.
Or, for the opposite point of view, if you have:
sub log { print STDERR localtime() . ": @_\n" }
then you better darn well invoke it as:
&log("my message");
and *not*:
log("my message"); # invokes built-in logarithm function
And until you know all the perl built-ins, you should use &. And this
is what we teach in Learning Perl.
Please don't be so quick to dismiss the value of the leading &.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<mer...@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
--
Posted via a free Usenet account from http://www.teranews.com
~greg
"Randal L. Schwartz" <mer...@stonehenge.com> wrote in message news:867io7t...@blue.stonehenge.com...
Ah so!
"Ambiguous call resolved as CORE::log(),
qualify as such or use & at ...
Argument "my message" isn't numeric in log at ...
Can't take log of 0 at ... "
And here I had always just implicitly assumed that a user defined
function would override and hide a built-in!
But then again I have always capitalize my own function names -
sub Log { ... }
So unless there are caplitalized built-ins,
then that should keep me out of this kind of trouble, no?
~greg
Randal L. Schwartz
~greg> It is still required,
~greg> but only when dealing with references (I think)
Or when dealing with a subroutine that is the same name as a built-in.
See my other post.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<mer...@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
--
~greg
> > ....
I wrote >
> But then again I have always capitalize my own function names -
> sub Log { ... }
> So unless there are caplitalized built-ins,
> then that should keep me out of this kind of trouble, no?
> ~greg
I call it "the ~gregian transform".
Not too profound - just a little trick to efficiently
keep me out of that kind of trouble and off the streets.
;)
~greg
Paul Lalli
> Or, for the opposite point of view, if you have:
>
> sub log { print STDERR localtime() . ": @_\n" }
>
> then you better darn well invoke it as:
>
> &log("my message");
>
> and *not*:
>
> log("my message"); # invokes built-in logarithm function
>
> And until you know all the perl built-ins, you should use &.
The difference, of course, is that failing to use & when required will
generate a pretty explicit warning, while using it when you shouldn't
will not. That's why I generally tell my students this is the one
tiny piece of Learning Perl that I disagree with. :-/
Paul Lalli
Mirco Wahab
> It is still required,
> but only when dealing with references (I think)
And nonlocal context 'jumps':
...
sub indirect { print "otherthing\n@_\n" };
sub onething { goto &indirect; print "this wont show up\n" }
onething( qw'A B C' );
...
Regards
M.
John W. Krahn
>>>>>> "Sherm" == Sherm Pendley <spam...@dot-app.org> writes:
>
> Sherm> It *does* make a difference - if you don't know or understand what that
> Sherm> difference is, or you don't specifically want the behavior specified by
> Sherm> the &, you shouldn't use it.
>
> Or, for the opposite point of view, if you have:
>
> sub log { print STDERR localtime() . ": @_\n" }
>
> then you better darn well invoke it as:
>
> &log("my message");
>
> and *not*:
>
> log("my message"); # invokes built-in logarithm function
>
> And until you know all the perl built-ins, you should use &. And this
> is what we teach in Learning Perl.
>
> Please don't be so quick to dismiss the value of the leading &.
Fortunately the syntax highlighting in my editor of choice allows me to
distinguish between built-in functions and user defined subroutines.
:-)
John
--
Perl isn't a toolbox, but a small machine shop where you
can special-order certain sorts of tools at low cost and
in short order. -- Larry Wall
Big and Blue
>
> And until you know all the perl built-ins, you should use &. And this
> is what we teach in Learning Perl.
Teach them to test the code they write too and such issues would never
get into the wild.
--
Just because I've written it doesn't mean that
either you or I have to believe it.
tru...@gmail.com
> >>>>> "~greg" == ~greg <g...@remove-comcast.net> writes:
>
> ~greg> It is still required,
> ~greg> but only when dealing with references (I think)
>
> Or when dealing with a subroutine that is the same name as a built-in.
> See my other post.
>
In another situation, I find it most useful as well. For example, I
typically determine what to do in a script by checking an incoming
parameter of a form:
my $MODE=param('Mode');
{
no strict;
$MODE="GetLogin" unless $MODE; # default sub to execute
&$MODE; # else execute this sub
}
This saves a lot of 'if-else' chains. Just my 2 Canadian cents.
--
Amer Neely
Web Mechanic - www.webmechanic.softouch.on.ca
Paul Lalli
> I
> typically determine what to do in a script by checking an incoming
> parameter of a form:
>
> my $MODE=param('Mode');
> {
> no strict;
> $MODE="GetLogin" unless $MODE; # default sub to execute
> &$MODE; # else execute this sub
>
> }
>
> This saves a lot of 'if-else' chains. Just my 2 Canadian cents.
It's also a rather absurdly large security whole. You have no way of
knowing what that parameter is. You are making the assumption that
the only way to contact your CGI script is via your form. This is
incorrect. A user can contact your CGI script without ever going near
your form.
You are allowing your users to call any subroutine in your program.
Paul Lalli
anno...@radom.zrz.tu-berlin.de
> Randal L. Schwartz wrote:
> >>>>>> "Sherm" == Sherm Pendley <spam...@dot-app.org> writes:
> >
> > Sherm> It *does* make a difference - if you don't know or understand what that
> > Sherm> difference is, or you don't specifically want the behavior specified by
> > Sherm> the &, you shouldn't use it.
> >
> > Or, for the opposite point of view, if you have:
> >
> > sub log { print STDERR localtime() . ": @_\n" }
> >
> > then you better darn well invoke it as:
> >
> > &log("my message");
> >
> > and *not*:
> >
> > log("my message"); # invokes built-in logarithm function
> >
> > And until you know all the perl built-ins, you should use &. And this
> > is what we teach in Learning Perl.
> >
> > Please don't be so quick to dismiss the value of the leading &.
>
> Fortunately the syntax highlighting in my editor of choice allows me to
> distinguish between built-in functions and user defined subroutines.
>
> :-)
Ignoring the smiley for the moment, the problem with syntax highlighters
for Perl is that they aren't reliable. They tend to let you down
exactly in the marginal cases when you could use the help.
What's worse, sometimes a quirk in the syntax highlighter makes people
use non-obvious code because the highlighter can't cope with the obvious
solution.
Currently I'm still using vim's syntax highlighting only out of inertia.
One of these days I'm going to switch it off for good.
Anno
anno...@radom.zrz.tu-berlin.de
I don't see how it saves an "if". The "else..." comment is misleading.
You are making sure that $MODE points to a sub, and *then* (not "else")
you're executing it.
That aside, your code doesn't require an ampersand in the call.
"$MODE->()" would work just as well.
Anno
Paul Lalli
> <tru...@gmail.com> wrote in comp.lang.perl.misc:
> > my $MODE=param('Mode');
> > {
> > no strict;
> > $MODE="GetLogin" unless $MODE; # default sub to execute
> > &$MODE; # else execute this sub
> > }
>
> > This saves a lot of 'if-else' chains. Just my 2 Canadian cents.
>
> I don't see how it saves an "if". The "else..." comment is
> misleading.
> You are making sure that $MODE points to a sub, and *then*
> (not "else") you're executing it.
I'm assuming he meant it prevents the need for something like:
if ($MODE eq 'Foo') {
Foo();
} elsif ($MODE eq 'Bar') {
Bar();
} else {
GetLogin();
}
Really, he's talking about Symrefs here, which is not at all the same
issue as using an & or not on a subroutine.
Paul Lalli
Martijn Lievaart
> Ignoring the smiley for the moment, the problem with syntax highlighters
> for Perl is that they aren't reliable. They tend to let you down
> exactly in the marginal cases when you could use the help.
>
> What's worse, sometimes a quirk in the syntax highlighter makes people
> use non-obvious code because the highlighter can't cope with the obvious
> solution.
>
> Currently I'm still using vim's syntax highlighting only out of inertia.
> One of these days I'm going to switch it off for good.
Emacs suffers from much the same problems. F.i. quote like operators are
not properly recognized, making me write:
next if m'^#';
instead of
next if /^#/;
In general I can live with it though.
M4
anno...@radom.zrz.tu-berlin.de
Right, that makes sense. It would still be preferable to use a dispatch
table (untested):
my %func = map {
no strict 'refs';
( $_ => \ &{ $_ });
} qw( Foo Bar Baz);
my $mode = param( 'Mode');
( $func{ $mode} || \ &GetLogin)->()
That way the symrefs are restricted to the table setup where they will
only be used with the code-determined qw( Foo Bar Baz). Whatever
value $mode has at run time, only these functions or GetLogin will
be called. The original code could call anything an attacker happens
to know about.
Anno
A. Sinan Unur
news:1186563907....@d55g2000hsg.googlegroups.com:
The current exchange rate notwithstanding, not worth much, I am afraid.
The proper way to do this allows you to check if an invalid mode was
provided using a lookup table.
# untested code
my %mode_handlers = (
GetLogin => \&GetLogin,
...
);
my $mode = param('Mode');
my $handler;
if ( exists $mode_handlers{ $mode } ) {
$handler = $mode_handlers{ $mode } ;
}
unless ( defined $handler ) {
$handler = $mode_handlers{ GetLogin };
}
$handler->( ... );
__END__
The exists guard is necessary if you are running under mod_perl or
Fast::CGI or any other environment where you program is expected to
serve multiple requests.
Otherwise, each invalid mode request can increase the memory footprint
of your program.
Sinan
> --
> Amer Neely
Your sig separator is incorrect: It should be dash-dash-space-newline.
Yours is missing a space.
--
A. Sinan Unur <1u...@llenroc.ude.invalid>
(remove .invalid and
reverse each component for email address)
comp.lang.perl.misc
guidelines on the WWW:
http://augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.html
Thrill5
news:pan.2007.08...@rtij.nl.invlalid...
I use the now defunct ActiveState plug-in for Visual Studio 2003, and have
never had an issue with it not highlighting code correctly. The only reason
I still use VS2003 is because they don't have a plug-in for VS2005.
Randal L. Schwartz
Martijn> Emacs suffers from much the same problems. F.i. quote like operators are
Martijn> not properly recognized, making me write:
Martijn> next if m'^#';
Martijn> instead of
Martijn> next if /^#/;
Martijn> In general I can live with it though.
That's a flaw with perl-mode. cperl-mode is far better, and actively
maintained. First thing I do with an empty .emacs file is teach it
to replace perl mode with cperl-mode. :)
Lawrence Statton
> That's a flaw with perl-mode. cperl-mode is far better, and actively
> maintained. First thing I do with an empty .emacs file is teach it
> to replace perl mode with cperl-mode. :)
>
I agree with the solution to that *particular* problem, but as is oft
said: Nothing but perl can parse Perl with absolute certainty. While
cperl-mode does not get nearly as confused nearly as often as
perl-mode did, I have succeeded in confusing its parser on occasion.
That being said, what superior alternative does the grandparent poster
propose? Merely saying that the syntax-highlighter is imperfect does
not obviate the benefits that even a mediocre highlighter offers.
--
Lawrence Statton - lawre...@abaluon.abaom s/aba/c/g
Computer software consists of only two components: ones and
zeros, in roughly equal proportions. All that is required is to
place them into the correct order.
Martijn Lievaart
>>>>>> "Martijn" == Martijn Lievaart <m...@rtij.nl.invlalid> writes:
>
> Martijn> Emacs suffers from much the same problems. F.i. quote like
> operators are Martijn> not properly recognized, making me write:
>
> Martijn> next if m'^#';
>
> Martijn> instead of
>
> Martijn> next if /^#/;
>
> Martijn> In general I can live with it though.
>
> That's a flaw with perl-mode. cperl-mode is far better, and actively
> maintained. First thing I do with an empty .emacs file is teach it to
> replace perl mode with cperl-mode. :)
Can you give me the magic incantations? I'm not very fluent in emacs-lisp.
TIA,
M4
tru...@gmail.com
I see where that would be possible. But would a user not need to know
the name of a subroutine in my script? My goal is to try and combine
as many functions as possible into one script, rather than have 5 or 6
separate scripts to maintain. Which brings up a question: if a user
can call any subroutine in my script, what's to stop them from running
a separate script as well?
If there is no secure way to do this with this particular method I
would like to know so as to fix it.
tru...@gmail.com
You're right - I was a little hasty with my wording. And thanks for
the usage of $MODE sans the leading ampersand.
tru...@gmail.com
Ah, thank you for this suggestion. I will implement this in my
scripts.
--
Amer Neely
Web Mechanic - www.webmechanic.softouch.on.ca
>
> > --
> > Amer Neely
>
> Your sig separator is incorrect: It should be dash-dash-space-newline.
> Yours is missing a space.
>
Fixed now. Thanks.
Lawrence Statton
(defalias 'perl-mode 'cperl-mode)
anno...@radom.zrz.tu-berlin.de
> mer...@stonehenge.com (Randal L. Schwartz) writes:
> > That's a flaw with perl-mode. cperl-mode is far better, and actively
> > maintained. First thing I do with an empty .emacs file is teach it
> > to replace perl mode with cperl-mode. :)
> >
>
> I agree with the solution to that *particular* problem, but as is oft
> said: Nothing but perl can parse Perl with absolute certainty. While
> cperl-mode does not get nearly as confused nearly as often as
> perl-mode did, I have succeeded in confusing its parser on occasion.
>
> That being said, what superior alternative does the grandparent poster
> propose? Merely saying that the syntax-highlighter is imperfect does
> not obviate the benefits that even a mediocre highlighter offers.
Superiority is relative. For the moment I'm still using the highlighter
that comes with vim though I find some of its properties annoying. The
most significant problem is, as mentioned, the alternative of either
looking at mis-highlighted code or using a style I wouldn't use if
it weren't to appease the highlighter. More generally, I'm not too
fond of the fruit-salad-like appearance of highlighted code in general.
Most of the time I'm just ignoring the colors (and underlines, and
italics, and what have you).
I guess I'll switch to no syntax highlighting per default and enabling
it from case to case when I think it would help, with some key bindings
thrown in to switch quickly. It's a way to use a tool without it getting
in the way, or so I hope.
Anno
Eric Schwartz
>
> ~greg> It is still required,
> ~greg> but only when dealing with references (I think)
>
> Or when dealing with a subroutine that is the same name as a built-in.
> See my other post.
That falls under my "But Doctor, it hurts when I do that" rule.
Naming your subs with the same name as a built-in is a bad idea, and I
don't mind in the slightest that perl warns you about it (you *did*
enable warnings, didn't you?).
-=Eric
Paul Lalli
> On Aug 8, 6:39 am, Paul Lalli <mri...@gmail.com> wrote:
> > On Aug 8, 5:05 am, tru...@gmail.com wrote:
> > > my $MODE=param('Mode');
> > > {
> > > no strict;
> > > $MODE="GetLogin" unless $MODE; # default sub to execute
> > > &$MODE; # else execute this sub
>
> > > }
>
> > knowing what that parameter is. You are making the assumption
> > that the only way to contact your CGI script is via your
> > form. This is incorrect. A user can contact your CGI script
> > without ever going near your form.
>
> > You are allowing your users to call any subroutine in your
> > program.
> I see where that would be possible. But would a user not need
> to know the name of a subroutine in my script?
Yes he would. But how difficult is that? How difficult is it to just
*guess* for starters, but more specifically, your form's parameter
list is giving him at least a subset of all options.
> My goal is to try and combine as many functions as possible into
> one script, rather than have 5 or 6 separate scripts to maintain.
I have no idea what this issue has to do with the issue being
discussed.
> Which brings up a question: if a user
> can call any subroutine in my script, what's to stop them from
> running a separate script as well?
... absolutely nothing. You should write ALL scripts residing on a
publically accessable webserver to be secure, and to check that only
those who are running the script "correctly" can do anything. If I
randomly type the address to one of your CGI scripts into my browser's
address bar, passing it data of my own creation, your script should be
able to handle that gracefully and not do anything it shouldn't do.
> If there is no secure way to do this with this particular method I
> would like to know so as to fix it.
You've already been given (or considered yourself) a few ways to do
this correctly. Either create a dispatch table as Anno demonstrated,
or check the value of each parameter to make sure it matches an
acceptable value.
Paul Lalli
Martijn Lievaart
> In your .emacs file
>
> (defalias 'perl-mode 'cperl-mode)
Snarfed. Thanks!
M4
Lars Haugseth
The latter works like a charm here. Make sure you're using a recent
version of cperl-mode, though.
http://www.emacswiki.org/cgi-bin/wiki/CPerlMode
--
Lars Haugseth
"If anyone disagrees with anything I say, I am quite prepared not only to
retract it, but also to deny under oath that I ever said it." -Tom Lehrer
Peter Scott
> mer...@stonehenge.com (Randal L. Schwartz) writes:
>> That's a flaw with perl-mode. cperl-mode is far better, and actively
>> maintained. First thing I do with an empty .emacs file is teach it
>> to replace perl mode with cperl-mode. :)
>
> I agree with the solution to that *particular* problem, but as is oft
> said: Nothing but perl can parse Perl with absolute certainty. While
> cperl-mode does not get nearly as confused nearly as often as
> perl-mode did, I have succeeded in confusing its parser on occasion.
Me too. One reliable way of doing that is to use m or s as naked hash
keys. Still, happens seldom enough that it's worth it to me to work
around, usually with a comment that contains the delimiters it's looking
for.
--
Peter Scott
http://www.perlmedic.com/
http://www.perldebugged.com/