4 ms·

It used to be that gcc will warn against strtok and recommend strsep instead. Do not know what the status is today

by pasokan 8y ago

tinus_hn 8y ago
Strtok is not thread safe and can’t be made thread safe without changing the API. You should not use it.
- morbusfonticuli 8y ago
  > 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 https://linux.die.net/man/3/strtok_r
  - seba_dos1 8y ago
    ...with different API :P
    - enriquto 8y ago
      of course! the original API cannot be made re-entrant
- heinrichhartman 8y ago
  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?
  - Sharlin 8y ago
    Yes, as long as you can guarantee that there’s only one tokenization going on per thread at a time.
    - deleted 8y ago
      [deleted]
  - nly 8y ago
    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.
- zakk 8y ago
  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.
  - johnisgood 8y ago
    > 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?
    - enriquto 8y ago
      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.
deleted 8y ago
[deleted]

It used to be that gcc will warn against strtok and recommend strsep instead. Do not know what the status is today

tinus_hn 8y ago

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

morbusfonticuli 8y ago
> 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 https://linux.die.net/man/3/strtok_r
- seba_dos1 8y ago
  ...with different API :P
  - enriquto 8y ago
    of course! the original API cannot be made re-entrant
heinrichhartman 8y ago
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?
- Sharlin 8y ago
  Yes, as long as you can guarantee that there’s only one tokenization going on per thread at a time.
  - deleted 8y ago
    [deleted]
- nly 8y ago
  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.
zakk 8y ago
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.
- johnisgood 8y ago
  > 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?
  - enriquto 8y ago
    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.

deleted 8y ago

[deleted]