Re: [PATCH] git-send-email: don't return undefined value in extract_valid_address()

From: Krzysztof Mazur <krzysiek@podlesie.net>
Date: Nov 20, 2012, 20:47 UTC
Message-ID: <20121120204736.GA7039@shrek.podlesie.net>
In-Reply-To: <7v8v9wrpdz.fsf@alter.siamese.dyndns.org>

On Tue, Nov 20, 2012 at 12:27:36PM -0800, Junio C Hamano wrote:

Show 6 quoted lines

> Krzysztof Mazur <krzysiek@podlesie.net> writes:
> 
> > In the fallback check, when Email::Valid is not available, the
> > extract_valid_address() does not check for success of matching regex,
> > and $1, which can be undefined, is always returned. Now if match
> > fails an empty string is returned.

Maybe the last line of comment should be changed to:

fails an empty string is returned to indicate failure.

> 
> That much we can read from the code, but a bigger question is why
> would it be a good thing for the callers?  Wouldn't they want to
> be able to distinguish a failure from an empty string?

In this case returning empty string does not make sense, so it's really used to indicate failure.

Show 15 quoted lines

> 
> > Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net>
> > ---
> > This fixes following warnings:
> > Use of uninitialized value in string eq at ./git-send-email.perl line 1017.
> > Use of uninitialized value in quotemeta at ./git-send-email.perl line 1017.
> > W: unable to extract a valid address from: x a.patch
> >
> > when invalid email address was added by --cc-cmd,
> > ./git-send-email.perl --dry-run --to a@podlesie.net --cc-cmd=echo x a.patch
> 
> In other words, would we want to *hide* (not "fix") the warning?
> Shouldn't we be barfing loudly and possibly erroring it out until
> the user fixes her --cc-cmd?
>

Yes, it's just to hide the warning, the error (warning in this case) it's already correctly generated:

W: unable to extract a valid address from: x a.patch

Maybe we should change it to an error?

Krzysiek