Joe Perches <joe@xxxxxxxxxxx> writes:
> + if (defined $to_cmd) {
> + open(F, "$to_cmd \Q$t\E |")
> + or die "(to-cmd) Could not execute '$to_cmd'";
> + while(<F>) {
> + my $t = $_;
"my $t" masks another $t in the outer scope; technically not a bug, but
questionable as a style.
> + $t =~ s/^\s*//g;
> + $t =~ s/\n$//g;
> + next if ($t eq $sender and $suppress_from);
> + push @to, parse_address_line($t)
> + if defined $t; # sanitized/validated later
This "if defined $t" makes my head hurt. Why?
* The "while (<F>)" loop wouldn't have given you an undef in $t in the
first place;
* You would have got "Use of uninitialized value" warning at these two
s/// statements if $t were undef; and
* Even if $t were undef, these two s/// statements would have made $t a
defined, empty string.
> + printf("(to-cmd) Adding To: %s from: '%s'\n",
> + $t, $to_cmd) unless $quiet;
> + }
> + close F
> + or die "(to-cmd) failed to close pipe to '$to_cmd'";
> + }
In any case, this whole codeblock obviously is a copy-and-paste from
corresponding $cc_cmd codepath, and I wonder if you can refactor the
original into a common helper function first and then use it to make the
addition of this feature a smaller patch.
if (defined $cc_cmd) {
push @cc, recipients_cmd($cc_cmd, 'cc');
}
if (defined $to_cmd) {
push @to, recipients_cmd($to_cmd, 'to');
}
If you did so, the first patch that refactors to create a helper function
can address issues Ãvar raised in the review to clean things up, no?
I notice that you use parse_address_line() while $cc_cmd codepath doesn't.
I haven't studied other codepaths deeply, but my gut feeling is that the
reason why the $cc_cmd codepath does not call parse_address_line() before
pushing the result to @cc is _not_ because strings on @cc shouldn't be
sanitized (the codepath to parse "Cc: " calls parse_address_line and
pushes the result to @cc), but because the code is simply sloppy. So I
suspect that it would be Ok for recipients_cmd to call parse_address_line
unconditionally.
Hmm?
--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
