This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [PATCH] Prefer strtok_r to strtok
- From: Nathan Myers <ncm-nospam at cantrip dot org>
- To: libstdc++ at gcc dot gnu dot org
- Date: Mon, 25 Nov 2002 22:05:01 +0000
- Subject: Re: [PATCH] Prefer strtok_r to strtok
- References: <3DE295AF.4050303@unitus.it>
This is what I mean. strtok is a trap. Look:
On Mon, Nov 25, 2002 at 10:27:11PM +0100, Paolo Carlini wrote:
> 2002-11-25 Paolo Carlini <pcarlini@unitus.it>
>
> * src/localename.cc
> (locale::_Impl::_Impl(const char*, size_t)): Prefer strtok_r
> to strtok for thread safety reasons.
> --- localename.cc.~1.31.~ 2002-10-11 09:09:36.000000000 +0200
> +++ localename.cc 2002-11-25 22:16:49.000000000 +0100
> @@ -155,17 +155,18 @@
> {
> char* __tmp = strdup(__s);
> __tmp[strlen(__tmp)] = ';';
> - strtok(__tmp, "=;");
> + char* __save;
> + strtok_r(__tmp, "=;", &__save);
Why not
char const* __save = __s;
> for (size_t __i = 0;
> __i < _S_categories_size + _S_extra_categories_size - 1; ++__i)
> {
> - char* __src = strtok(NULL, "=;");
> + char* __src = strtok_r(NULL, "=;", &__save);
> char* __new = new char[strlen(__src) + 1];
> strcpy(__new, __src);
> _M_names[__i] = __new;
> - strtok(NULL, "=;");
> + strtok_r(NULL, "=;", &__save);
and something like
char const* __next = __save + strcspn(__save, "=;");
// if (__next == __save) throw 1/0; // us, error checking?.
_M_names[__i] = std::string<char>(__save, __next);
__save = __next + 1;
> }
> - char* __src = strtok(NULL, "=;");
> + char* __src = strtok_r(NULL, "=;", &__save);
> char* __new = new char[strlen(__src) + 1];
> strcpy(__new, __src);
> _M_names[_S_categories_size + _S_extra_categories_size - 1] = __new;
and so on, accordingly. (Is there some reason the last bit can't be
folded into the loop?)
No __tmp to strdup into, no __new to malloc, no flaky POSIXism to depend
on, and shorter. (Of course the code above is untested.)
BTW, is this function supposed to handle bad input (e.g. too few fields,
empty fields, etc.) safely? It seems to me that users put these strings
into environment variables, and this might allow them to corrupt
otherwise-trusted programs.
Nathan Myers
ncm-nospam@cantrip.org