MIME-Version: 1.0
Date: Wed, 23 Jul 2025 00:34:05 +0300
From: Dmitry Mityugov <d.mityugov@postgrespro.ru>
To: Corey Huinker <corey.huinker@gmail.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: [PATCH] Use strchr() to search for a single character
In-Reply-To: 
 <CADkLM=eZe5qp+_6ZifQhxYtvhYOTr-AydsWvXhPe2mZs=9npTw@mail.gmail.com>
References: <9c1beea6c7a5e9fb6677f26620f1f257@postgrespro.ru>
 <CADkLM=eZe5qp+_6ZifQhxYtvhYOTr-AydsWvXhPe2mZs=9npTw@mail.gmail.com>
Message-ID: <8d327aa3460fa78d0d1bdcaa46f5df78@postgrespro.ru>
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/8d327aa3460fa78d0d1bdcaa46f5df78%40postgrespro.ru>
Precedence: bulk

Corey Huinker писал(а) 2025-07-22 22:42:
> On Sun, Jul 20, 2025 at 6:21 PM Dmitry Mityugov
> <d.mityugov@postgrespro.ru> wrote:
> 
>> Code in src/port/pgmkdirp.c uses strstr() to find a single character
>> in
>> a string, but strstr() seems to be too generic for this job. Another
>> 
>> function, strchr(), might be better suited for this purpose, because
>> it
>> is optimized to search for exactly one character in a string. In
>> addition, if strchr() is used, the compiler doesn't have to generate
>> a
>> terminating \0 byte for the substring, producing slightly smaller
>> code.
>> I'm attaching the patch.
>> 
>> Regards,
>> Dmitry
> 
> Seems like a simple-enough change, not a huge win but probably worth
> doing.
> 
> Using ripgrep to search for 'strstr(.*".")' turns up two similar
> situations in contrib/fuzzystrmatch/dmetaphone.c, so perhaps we
> include those.
> 
> There's also a match in src/bin/pg_rewind/filemap.c, but that one is a
> false positive.

Thank you for your attention to this problem. The code in 
contrib/fuzzystrmatch/dmetaphone.c indeed uses several calls to strstr() 
to search for a single character, but it also uses strstr() to search 
for strings that consist of more than a single character on adjacent 
lines, and replacing half of those strstr()s with strchr()s would make 
the code less consistent in my opinion.

What's more important, it seems that this code in 
contrib/fuzzystrmatch/dmetaphone.c contains a bug. Statement `else if 
(strstr(s->str, "WITZ"))` at line 317 will never be executed, because if 
the string contains substring “W”, it will be handled at line 311, `if 
(strstr(s->str, "W"))`. Probably this bug should be fixed in a separate 
commit.