Re: replace strtok() - Mailing list pgsql-hackers

From Ranier Vilela
Subject Re: replace strtok()
Date
Msg-id CAEudQApMiHHpx_GA96B8RMWpJ42CEYD4MjtvJpfj7cXrjn8i=Q@mail.gmail.com
Whole thread Raw
In response to replace strtok()  (Peter Eisentraut <peter@eisentraut.org>)
Responses Re: replace strtok()
List pgsql-hackers
Em ter., 18 de jun. de 2024 às 04:18, Peter Eisentraut <peter@eisentraut.org> escreveu:
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.
+1 For making the code thread-safe.
But I would like to see more const char * where this is possible.

For example, in pg_locale.c
IMO, the token variable can be const char *.

At least strchr expects a const char * as the first parameter.

I found another implementation of strsep, it seems lighter to me.
I will attach it for consideration, however, I have not done any testing. 

best regards,
Ranier Vilela
Attachment

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: DOCS: Generated table columns are skipped by logical replication
Next
From: Peter Eisentraut
Date:
Subject: jsonapi type fixups