summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorTaylor Blau <me@ttaylorr.com>2023-04-24 18:20:26 -0400
committerJunio C Hamano <gitster@pobox.com>2023-04-27 08:51:11 -0700
commit60ff56f50372c1498718938ef504e744fe011ffb (patch)
treea897a72bfda040494be0a95562bbcb3f59278ace
parenta2742f8c59dae6ef55895933e0950d61b6d03720 (diff)
downloadgit-60ff56f50372c1498718938ef504e744fe011ffb.tar.gz
banned.h: mark `strtok()` and `strtok_r()` as banned
`strtok()` has a couple of drawbacks that make it undesirable to have any new instances. In addition to being thread-unsafe, it also encourages confusing data flows, where `strtok()` may be called from multiple functions with its first argument as NULL, making it unclear from the immediate context which string is being tokenized. Now that we have removed all instances of `strtok()` from the tree, let's ban `strtok()` to avoid introducing new ones in the future. If new callers should arise, they are encouraged to use `string_list_split_in_place()` (and `string_list_remove_empty_items()`, if applicable). string_list_split_in_place() is not a perfect drop-in replacement for `strtok_r()`, particularly if the caller is processing a string with an arbitrary number of tokens, and wants to process each token one at a time. But there are no instances of this in Git's tree which are more well-suited to `strtok_r()` than the friendlier `string_list_split_in_place()`, so ban `strtok_r()`, too. Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
-rw-r--r--banned.h4
1 files changed, 4 insertions, 0 deletions
diff --git a/banned.h b/banned.h
index 6ccf46bc19..44e76bd90a 100644
--- a/banned.h
+++ b/banned.h
@@ -18,6 +18,10 @@
#define strncpy(x,y,n) BANNED(strncpy)
#undef strncat
#define strncat(x,y,n) BANNED(strncat)
+#undef strtok
+#define strtok(x,y) BANNED(strtok)
+#undef strtok_r
+#define strtok_r(x,y,z) BANNED(strtok_r)
#undef sprintf
#undef vsprintf