`strtok_r()` is reentrant, but `strtok()` is not, meaning that using it
is not thread-safe.
We could ban `strtok()` and force callers to use its reentrant
counterpart, but there are a few drawbacks to doing so:
- `strtok_r()` forces the caller to maintain an extra string pointer
to pass as its `saveptr` value
- `strtok_r()` also requires that its `saveptr` value be unmodified
between calls.
- `strtok()` (and by extension, `strtok_r()`) is confusing when used
across multiple functions, since the caller is supposed to pass NULL
as its first argument after the first call. This makes it difficult
to determine what string is actually being tokenized without clear
dataflow.
So while we could ban only `strtok()`, there really is no good reason to
use either when callers could instead use the much friendlier
`string_list_split_in_place()` API, which avoids the above issues.
Signed-off-by: Taylor Blau <me@xxxxxxxxxxxx>
---
banned.h | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/banned.h b/banned.h
index 6ccf46bc197..9bd23ce5732 100644
--- a/banned.h
+++ b/banned.h
@@ -18,6 +18,12 @@
#define strncpy(x,y,n) BANNED(strncpy)
#undef strncat
#define strncat(x,y,n) BANNED(strncat)
+#if 0
+#undef strtok
+#define strtok(x,y) BANNED(strtok)
+#undef strtok_r
+#define strtok_r(x,y,z) BANNED(strtok_r)
+#endif
#undef sprintf
#undef vsprintf
--
2.38.0.16.g393fd4c6db
