Hacker News Reader

Comment by tinus_hn | Hacker News Reader

Strtok is not thread safe and can’t be made thread safe without changing the API. You should not use it.

> Strtok is not thread safe and can’t be made thread safe without changing the API. You should not use it.

Well, there is already a thread-safe variant [0]: > The strtok() function uses a static buffer while parsing, so it's not thread safe. Use strtok_r() if this matters to you.

[0] https://linux.die.net/man/3/strtok_r

...with different API :P

of course! the original API cannot be made re-entrant

Well, strtok could use thread local variables to store intermediate state, to make it threadsafe while maintaining the same API. Not saying this is a good idea, but technically it would work, no?

Yes, as long as you can guarantee that there’s only one tokenization going on per thread at a time.

You could, but that would change the behaviour of existing programs. It might well be that there are well-defined programs out there that use strtok across separate, but properly synchronized, threads.

This is why it's crucial to get APIs right first time.

That’s not a good reason not to use it.

A function can be not thread-safe and still safe to use in single-threaded programs.

The point is that strtok is not a good choice even for single-threaded code.

> The point is that strtok is not a good choice even for single-threaded code.

Why isn't it a good choice exactly? Could you sum it up?

Maybe he means that the function is not re-entrant. You cannot run a loop that tokenizes a string, and somewhere inside, you call a function that uses strtok itself. This can happen inadvertently.

Reply on news.ycombinator.com