in reply to Modifying Arrays passed by reference to subroutine

You are very close! First enable run time warnings (the -w flag) and use strict (first 2 lines of code below). There is no sub called main{} in a Perl program this is not Java. I wouldn't put these checks for undef input parameters. The runtime warnings will show error if that happens. Basically have have the right idea and your code runs! 
#!/usr/bin/perl -w
use strict;

my @broken = (1,2,3);
my $location = "/home/user/";
find_broken_links( $location, \@broken );
foreach my $var (@broken)
{
    print "Returned: $var\n";
}


sub find_broken_links
{
  my ($location, $broken_links) = @_;
  # other code not shown here
  my $var ='X';
  push @$broken_links, $var;
}

#prints:
#Returned: 1
#Returned: 2
#Returned: 3
#Returned: X

[download]
Update:I see some other posts while I was writing mine. The "stringification" as AnomalousMonk points out is a problem. The code I wrote just automatically didn't have that condition and so it worked. I would caution against this type of "silent program error". These sub input params will be undefined if there is an error in the calling program. If that is the case, you want to know about it! Otherwise your code would just simply return with apparently no broken links found, which probably is not what you want to have happen!

Replies are listed 'Best First'.
Re^2: Modifying Arrays passed by reference to subroutine
by akho (Hermit) on Jun 09, 2009 at 07:13 UTC
    perllexwarn explains why use warnings is better than -w. use warnings FATAL => 'all' is even better than use warnings. And if you expect warnings to do parameter validation for you, you should be extra careful. It's usually easier to check them.
[reply]
[d/l]
[select]
      This reference to perllexwar basically says that the problem can be that you turn warnings ON for more than maybe you want to.

      I figure that more aggressive warnings are usually better than less aggressive. If you get warnings that you decide are not warranted, then you can "crank down the warning level" for that segment of code, but usually (in my opinion) that's the wrong thing to do unless you are extremely clear about why you are going that.

      As far as parm validation goes, there is a whole bunch that didn't get talked about for this code example....use of prototypes in Perl functions, etc. In this case the issue was defined or not which is different than say param #3 should be between 4 and 12.

      In any event, I think that it is wrong to return silently when the sub fails.

      Update: In any event, I think that it is wrong to silently return a valid return value when the sub fails.

[reply]
        My point was that sometimes undef may not lead to a warning, but your sub won't do what you expect it to. Lack of proper sub signatures is sometimes annoying.

        perllexwarn also talks about code in modules; -w enables warnings anywhere, so other people's code (i.e. those people who knew what they were doing and turned off warnings for relevant parts of their code) will throw warnings at you. It may be a lot of warnings.

        "Throwing a warning" is exactly equivalent to "returning useless stuff silently" in most scenarios; warnings are written to stderr, which is not available for a lot of programs. And even if it is available — most end users just ignore it. If your code is potentially destructive (and what code isn't) you should die in unexpected situations, not issue a warning.

        Also: use warnings FATAL => 'all' is much more aggressive than -w.

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom