[ Brian Behlendorf writes: ]
>
> On Tue, 24 Sep 1996, Rick Franchuk wrote:
> >
> > 1.94 beta 2 seems to have the odd problem or two. First one is in
> > 'resend', where my machine barfed on a 'restrict_post' entry... a bit
> > of debugging showed that the response coming from &check_sender was the
> > first line of text from the message being sent, confusing the hell out
> > of checks after it returned. Fixed by adding a set of ""'s to the
> > returns of check_sender (diffs available upon request).
>
> I can verify this bug exists with Perl 4.036 and MD 1.94b3. The
> fix recommended by Rick, which is exactly what I'm using too, is
> attached as a patch. I am not confident I understand why one needs to
> explicitly
>
> return "";
>
> instead of just
>
> return;
>
> but it does seem ugly. I haven't tested to see if Perl 5 works the same
> way, but I suspect that this hasn't been noticed if it was just a Perl 4
> issue...
It's a problem the code. Return is defined as 'return <list>'. There
is no alternate without the <list> operand. None of the documentation
details what is returned when no operand is specified, but I suspect it
simply returns the value of the last expression before the return.
If the return value from a subroutine is always discarded, then it
doesn't matter what is specified, if anything, as the operand of return.
In this case, however, the return value of check_sender() *is* used, but
in 2 instances no return value is specified, so it's not surprising that
garbage is returned.
The bottom line is that if one want's to return a null string, then
return a null string, but don't expect an unspecified return to be a
null string. Although the fix may be "ugly", it's correct. Do you like
return ();
any better?
--
Dave Wolfe *Not a spokesman for Motorola*
Motorola MMTG 6501 Wm. Cannon Dr. W. OE112 Austin TX 78735-8598
References:
|
|
