Horton

replace strtok()

Peter Eisentraut <peter@eisentraut.org>

View thread View on postgr.es
From: Peter Eisentraut <peter@eisentraut.org>
To: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2024-06-18T07:18:28Z
Lists: pgsql-hackers

Attachments

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

Commits

  1. Fix memory leaks from incorrect strsep() uses

  2. Fix strsep() use for SCRAM secrets parsing

  3. Replace remaining strtok() with strtok_r()

  4. Windows replacement for strtok_r()

  5. Replace some strtok() with strsep()

  6. Add port/ replacement for strsep()