replace strtok()

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: replace strtok()
Date: 2024-06-18 07:18:28
Message-ID: 79692bf9-17d3-41e6-b9c9-fc8c3944222a@eisentraut.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Under the topic of getting rid of thread-unsafe functions in the backend
[0], here is a patch series to deal with strtok().

Of course, strtok() is famously not thread-safe and can be replaced by
strtok_r(). But it also has the wrong semantics in some cases, because
it considers adjacent delimiters to be one delimiter. So if you parse

SCRAM-SHA-256$<iterations>:<salt>$<storedkey>:<serverkey>

with strtok(), then

SCRAM-SHA-256$$<iterations>::<salt>$$<storedkey>::<serverkey>

parses just the same. In many cases, this is arguably wrong and could
hide mistakes.

So I'm suggesting to use strsep() in those places. strsep() is
nonstandard but widely available.

There are a few places where strtok() has the right semantics, such as
parsing tokens separated by whitespace. For those, I'm using strtok_r().

A reviewer job here would be to check whether I made that distinction
correctly in each case.

On the portability side, I'm including a port/ replacement for strsep()
and some workaround to get strtok_r() for Windows. I have included
these here as separate patches for clarity.

[0]:
https://www.postgresql.org/message-id/856e5ec3-879f-42ee-8258-8bcc6ec9bdea@eisentraut.org

Attachment Content-Type Size
v1-0001-Replace-some-strtok-with-strsep.patch text/plain 3.3 KB
v1-0002-Replace-remaining-strtok-with-strtok_r.patch text/plain 2.6 KB
v1-0003-Add-port-replacement-for-strsep.patch text/plain 6.8 KB
v1-0004-Windows-replacement-for-strtok_r.patch text/plain 749 bytes

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Euler Taveira 2024-06-18 07:23:52 Re: speed up a logical replica setup
Previous Message Euler Taveira 2024-06-18 07:10:51 Re: State of pg_createsubscriber