From lr@hpllr1.hpl.hp.com

This is a bug report for perl from lr@​hpl.hp.com,
generated with the help of perlbug 1.12 running under perl 5.00503.

[Please enter your report here]

#!/usr/local/bin/perl -w
use strict;

sub f { print +(caller 0)[4], "\n" }

f;
&f;
f();
&f();
f(@​ARGV);
&f(@​ARGV);
__END__

Output​:

1
0
1
1
1
1

The first three '1' values are incorrect, because the call has no arguments.

I have confirmed the same behavior on ActivePerl 5.6.0 on Windows NT.

Site configuration information for perl 5.00503​:

Configured by lr at Wed Jul 21 17​:32​:46 PDT 1999.

Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration​:
  Platform​:
  osname=hpux, osvers=09.05, archname=PA-RISC1.1
  uname='hp-ux pss a.09.05 a 9000735 2004833812 two-user license '
  hint=recommended, useposix=true, d_sigaction=define
  usethreads=undef useperlio=undef d_sfio=undef
  Compiler​:
  cc='cc', optimize='-O', gccversion=
  cppflags='-D_HPUX_SOURCE -Aa -I/usr/local/include'
  ccflags ='-D_HPUX_SOURCE -Aa -I/usr/local/include'
  stdchar='unsigned char', d_stdstdio=define, usevfork=false
  intsize=4, longsize=4, ptrsize=4, doublesize=8
  d_longlong=undef, longlongsize=, d_longdbl=define, longdblsize=16
  alignbytes=8, usemymalloc=y, prototype=define
  Linker and Libraries​:
  ld='ld', ldflags =' -L/usr/local/lib'
  libpth=/usr/local/lib /lib/pa1.1 /lib /usr/lib
  libs=-lndbm -lgdbm -ldld -lm -lc -lndir -lcrypt
  libc=/lib/libc.sl, so=sl, useshrplib=false, libperl=libperl.a
  Dynamic Linking​:
  dlsrc=dl_hpux.xs, dlext=sl, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-B,deferred '
  cccdlflags='+z', lddlflags='-b -L/usr/local/lib'

From [Unknown Contact. See original ticket]

On Thu, 4 May 2000, Larry Rosler wrote​:

The first three '1' values are incorrect, because the call has no arguments.

From perlvar​:

  Subroutines may be called recursively. If a subroutine is
  called using the "&" form, the argument list is optional,
  and if omitted, no @​_ array is set up for the subroutine​:
  the @​_ array at the time of the call is visible to
  subroutine instead. This is an efficiency mechanism that
  new users may wish to avoid.

  &foo(1,2,3); # pass three arguments
  foo(1,2,3); # the same

  foo(); # pass a null list
  &foo(); # the same

  &foo; # foo() get current args, like foo(@​_) !!
  foo; # like foo() IFF sub foo predeclared, else "foo"

  Not only does the "&" form make the argument list
  optional, but it also disables any prototype checking on
  the arguments you do provide. This is partly for
  historical reasons, and partly for having a convenient way
  to cheat if you know what you're doing. See the section
  on Prototypes below.

From [Unknown Contact. See original ticket]

From​: Aaron J Mackey [mailto​:ajm6q@​virginia.edu]
Sent​: Thursday, May 04, 2000 12​:08
To​: lr@​hpl.hp.com
Cc​: perl5-porters@​perl.org
Subject​: Re​: [ID 20000504.001] $hasargs return from caller(0)
is bogus.

Thanks for your prompt and, ultimately, demystifying response.

On Thu, 4 May 2000, Larry Rosler wrote​:

The first three '1' values are incorrect, because the call
has no arguments.

From perlvar​:

No, it is from perlsub.

   Subroutines may be called recursively\.  If a subroutine is
   called using the "&" form\, the argument list is optional\,
   and if omitted\, no @​\_ array is set up for the subroutine​:
   the @​\_ array at the time of the call is visible to
   subroutine instead\.  This is an efficiency mechanism that
   new users may wish to avoid\.

       &foo\(1\,2\,3\);        \# pass three arguments
       foo\(1\,2\,3\);         \# the same

       foo\(\);              \# pass a null list
       &foo\(\);             \# the same

       &foo;               \# foo\(\) get current args\, like
                                 foo\(@​\_\) \!\!
       foo;                \# like foo\(\) IFF sub foo
                                 predeclared\, else "foo"

The first sentence is misleadingly irrelevant to the rest of the
paragraph. It should be in a paragraph of its own.

After much re-reading, I conclude that $hasargs means that a @​_ has been
set up for this call, though the list may be null. The only situation
in which no @​_ is set up is the plain &foo; call, for which $hasargs is
zero.

I suggest that as $hasargs is undocumented in perlfunc -f caller, that
this bug report be treated as a documentation request, and that some
documentation along the lines of the preceding paragraph be added there.

From [Unknown Contact. See original ticket]

"Larry Rosler" <lr@​hpl.hp.com> wrote

I suggest that as $hasargs is undocumented in perlfunc -f caller, that
this bug report be treated as a documentation request, and that some
documentation along the lines of the preceding paragraph be added there.

Like this? (patch for 5.6.0)

Mike Guy

--- ./pod/perlfunc.pod.orig	Wed Apr 26 16:24:55 2000
+++ ./pod/perlfunc.pod	Fri May  5 18:35:21 2000
@@ -539,9 +539,10 @@
 call, but an C<eval>.  In such a case additional elements $evaltext and
 C<$is_require> are set: C<$is_require> is true if the frame is created by a
 C<require> or C<use> statement, $evaltext contains the text of the
-C<eval EXPR> statement.  In particular, for a C<eval BLOCK> statement,
+C<eval EXPR> statement.  In particular, for an C<eval BLOCK> statement,
 $filename is C<(eval)>, but $evaltext is undefined.  (Note also that
 each C<use> statement creates a C<require> frame inside an C<eval EXPR>)
+frame.  C<$hasargs> is true if a new instance of C<@_> was set up for the
 frame.  C<$hints> and C<$bitmask> contain pragmatic hints that the caller
 was compiled with.  The C<$hints> and C<$bitmask> values are subject to
 change between versions of Perl, and are not meant for external use.

End of patch

From [Unknown Contact. See original ticket]

From​: M.J.T. Guy [mailto​:mjtg@​cus.cam.ac.uk]
Sent​: Friday, May 05, 2000 10​:39
To​: lr@​hpl.hp.com; perl5-porters@​perl.org
Subject​: Re​: [ID 20000504.001] $hasargs return from caller(0) is bogus

"Larry Rosler" <lr@​hpl.hp.com> wrote

I suggest that as $hasargs is undocumented in perlfunc -f caller,
that
this bug report be treated as a documentation request, and that some
documentation along the lines of the preceding paragraph be added
there.

Like this? (patch for 5.6.0)

Mike Guy

--- ./pod/perlfunc.pod.orig Wed Apr 26 16​:24​:55 2000
+++ ./pod/perlfunc.pod Fri May 5 18​:35​:21 2000
@​@​ -539,9 +539,10 @​@​
call, but an C<eval>. In such a case additional elements $evaltext
and
C<$is_require> are set​: C<$is_require> is true if the frame is
created by a
C<require> or C<use> statement, $evaltext contains the text of the
-C<eval EXPR> statement. In particular, for a C<eval BLOCK>
statement,
+C<eval EXPR> statement. In particular, for an C<eval BLOCK>
statement,
$filename is C<(eval)>, but $evaltext is undefined. (Note also that
each C<use> statement creates a C<require> frame inside an C<eval
EXPR>)
+frame. C<$hasargs> is true if a new instance of C<@​_> was set up for
the
frame. C<$hints> and C<$bitmask> contain pragmatic hints that the
caller
was compiled with. The C<$hints> and C<$bitmask> values are subject
to
change between versions of Perl, and are not meant for external use.

End of patch

It's a lot better than what is there now (nothing). One might choose to
be more explanatory​:

C<$hasargs> is true if a new instance of C<@​_> was set up for the frame
(i.e., for any call except of the form C<&foo> with no argument list).

Larry

From @floatingatoll

The documentation patches suggested in this ticket have been included into
5.8.0. Thanks!

- R.

@floatingatoll - Status changed from 'open' to 'resolved'