Perl Bug?

[akim]

Hi

I think I met a bug in Perl.  I'm running

----------------------------------------
~/src/am % perl --version                                            22:29 remo

This is perl, version 5.005_03 built for i386-linux

Copyright 1987-1999, Larry Wall

Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 5.0 source kit.

Complete documentation for Perl, including FAQ lists, should be found on
this system using `man perl' or `perldoc perl'.  If you have access to the
Internet, point your browser at http://www.perl.com/, the Perl Home Page.
----------------------------------------

I really can't find a means to make myself responsible of this
problem.  I'd like help from someone.



First the patch to apply to automake.in to highlight what I'm tempted
to call a bug:


----------------------------------------
prcs: Producing diffs from 0.31 to 0.31(w).
Index: automake.in
--- automake.in Thu, 01 Feb 2001 22:11:21 +0100 akim (am/f/39_automake.i 1.28 
755)
+++ automake.in Thu, 01 Feb 2001 22:27:55 +0100 akim (am/f/39_automake.i 1.28 
755)
@@ -4284,16 +4284,19 @@ sub handle_minor_options
 # (or AC_OUTPUT).
 sub scan_autoconf_config_files
 {
+    print STDERR "=>> @_\n";
+    print STDERR "==>> $_\n";
     # Look at potential Makefile.am's.
     foreach (split)
     {
+        print STDERR "=> $_\n";
         # Must skip empty string for Perl 4.
         next if $_ eq "\\" || $_ eq '';

         # Handle $local:$input syntax.  Note that we ignore
         # every input file past the first, though we keep
         # those around for later.
-        local ($local, $input, @rest) = split (/:/);
+        my ($local, $input, @rest) = split (/:/);
         if (! $input)
         {
             $input = $local;
@@ -4323,17 +4326,16 @@ sub scan_autoconf_config_files
 # &scan_autoconf_traces ($FILENAME)
 # ---------------------------------
 # FIXME: For the time being, we don't care about the FILENAME.
-sub scan_autoconf_traces
+sub scan_autoconf_traces ($)
 {
-    local ($filename) = @_;
-    local (*TRACES);
-
-    local ($traces) = "$ENV{amtraces} ";
+    my $filename = @_;

+    my $traces = "$ENV{amtraces} ";
     $traces .= ' -t AC_CONFIG_FILES';
     $traces .= ' -t AC_LIBSOURCE';
     $traces .= ' -t AC_SUBST';

+    local (*TRACES);
     open (TRACES, "$traces |")
        || die "automake: couldn't open \`$traces': $!\n";
     print "automake: reading $traces\n" if $verbose;
@@ -4341,13 +4343,14 @@ sub scan_autoconf_traces
     while (<TRACES>)
     {
         chomp;
-        local ($file, $line, $macro, @args) = split /:/;
+        local ($file, $line, $macro, @args) = split (/:/);
        local ($here) = "$file:$line";

        # Alphabetical ordering please.
         if ($macro eq 'AC_CONFIG_FILES')
        {
            # Look at potential Makefile.am's.
+           print STDERR "traces: study config files: $args[0]\n";
            &scan_autoconf_config_files ($args[0]);
        }
         elsif ($macro eq 'AC_LIBSOURCE')
----------------------------------------

Now if I run this automake on CVS Automake *using amtrace*, i.e.,
defining the envvar amtrace to point to autoconf from CVS Autoconf, I
get this:

traces: study config files: Makefile automake aclocal m4/Makefile tests/Makefile
=>> Makefile automake aclocal m4/Makefile tests/Makefile
==>> configure.in:18:AC_CONFIG_FILES:Makefile automake aclocal m4/Makefile 
tests/Makefile
=> configure.in:18:AC_CONFIG_FILES:Makefile
=> automake
=> aclocal
=> m4/Makefile
=> tests/Makefile


Line by line this is what happens:

| traces: study config files: Makefile automake aclocal m4/Makefile 
tests/Makefile

is coming from the lines:

        if ($macro eq 'AC_CONFIG_FILES')
        {
            # Look at potential Makefile.am's.
            print STDERR "traces: study config files: $args[0]\n";
            &scan_autoconf_config_files ($args[0]);
        }

so OK, it correctly received the first argument of AC_CONFIG_FILES in
$args[0].  It call &scan_autoconf_config_files with this list, and if
I display this list at the beginning of &scan_autoconf_config_files
using

    print STDERR "=>> @_\n";

I get:

=>> Makefile automake aclocal m4/Makefile tests/Makefile

Fine !

But in the very same function, if I use $_ instead of @_, which is
what the following line does:

    print STDERR "==>> $_\n";

I get:

==>> configure.in:18:AC_CONFIG_FILES:Makefile automake aclocal m4/Makefile 
tests/Makefile

and for whatever reason, suddenly, the location and name of the macro
invocation appears: `configure.in:18:AC_CONFIG_FILES:' (this guy are
supposed to be filtered out by a split (/:/) whcih defines $args[0]
*after* those those fields).

Then of course, and maybe this is the bug recently reported about
`amtraces is broken, please repear', I have automake which complains:

configure.in: 17: required file `./18' not found
configure.in: 17: required file `./AC_CONFIG_FILES' not found

so if someone could *explain* to me why this is what is to be
expected, then, fine!  If someone could tell me that a more recent
Perl does not have this behavior, then even better with me!  I'm all
in favor a `use'ing a more recent Perl, but I don't know Tom's
position about this.




Sure there are workarounds, and I guess (not tested yet) using `"@_"'
instead of `$_' is the way out.  Still, there is something I don't
get, and frankly, I'd like to hear from you `Yeah, this is definitely
a bug' (and bonus if you say `and it fixed in recent perls).

   Akim