Some dead code in metaphone() of fuzzystrmatch.c

Started by Michael Paquierabout 11 years ago2 messageshackers
Jump to latest
#1Michael Paquier
michael@paquier.xyz

Hi all,

In metaphone() we do the following:
/* return an empty string if we receive one */
if (!(str_i_len > 0))
PG_RETURN_TEXT_P(cstring_to_text(""));

if (str_i_len > MAX_METAPHONE_STRLEN)
ereport(ERROR,
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
errmsg("argument exceeds the maximum
length of %d bytes",
MAX_METAPHONE_STRLEN)));

if (!(str_i_len > 0))
ereport(ERROR,
(errcode(ERRCODE_ZERO_LENGTH_CHARACTER_STRING),
errmsg("argument is empty string")));
As we already return an empty string if the first condition is
satisfied, the third condition will never be satisfied. Returning an
empty string when output string is NULL has been introduced in commit
13629df of 2004, so I think that we should simply remove the code
block that will never be crossed, as in the patch attached.
Coverity has pointed out this issue.
Regards,
--
Michael

Attachments:

20150202_metaphone_deadblock.patchtext/x-diff; charset=US-ASCII; name=20150202_metaphone_deadblock.patchDownload+0-5
#2Heikki Linnakangas
heikki.linnakangas@enterprisedb.com
In reply to: Michael Paquier (#1)
Re: Some dead code in metaphone() of fuzzystrmatch.c

On 02/02/2015 03:39 AM, Michael Paquier wrote:

In metaphone() we do the following:
/* return an empty string if we receive one */
if (!(str_i_len > 0))
PG_RETURN_TEXT_P(cstring_to_text(""));

if (str_i_len > MAX_METAPHONE_STRLEN)
ereport(ERROR,
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
errmsg("argument exceeds the maximum
length of %d bytes",
MAX_METAPHONE_STRLEN)));

if (!(str_i_len > 0))
ereport(ERROR,
(errcode(ERRCODE_ZERO_LENGTH_CHARACTER_STRING),
errmsg("argument is empty string")));
As we already return an empty string if the first condition is
satisfied, the third condition will never be satisfied. Returning an
empty string when output string is NULL has been introduced in commit
13629df of 2004, so I think that we should simply remove the code
block that will never be crossed, as in the patch attached.

Applied, thanks.

- Heikki

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers