This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: strtok behaviour when uninitialized
On Mon, Feb 19, 2018 at 11:31:11AM +0100, Florian Weimer wrote:
> On 02/12/2018 01:09 AM, Rich Felker wrote:
> >On Sun, Feb 11, 2018 at 06:06:41PM -0500, Zack Weinberg wrote:
> >>On Sun, Feb 11, 2018 at 4:05 PM, Florian Weimer<fweimer@redhat.com> wrote:
> >>>On 02/11/2018 08:32 PM, Zack Weinberg wrote:
> >>>>With my security hat on, I would like glibc to define as many cases of
> >>>>undefined behavior as possible -- as prompt, guaranteed crashes.
> >>>>Defining the behavior as anything else leads to people relying on
> >>>>whatever the definition is, but leaving it as "whatever the code
> >>>>happens to do"_also_ leads to people relying on the actual behavior,
> >>>>plus it leaves room for exploits.
> >>>But in the case of strtok, the more relevant undefined behavior is that it's
> >>>not thread-safe. There's a fairly large number of libraries which reference
> >>>both pthread_create and strtok, which is rather sad.
> >>I don't particularly like saying this, but I think the only defensive
> >>measure that wouldn't cause more problems than it solves would be to
> >>make the persistent state for strtok be thread-local.
>
> >This is actually not permitted by the C language as specified. Under
> >7.24.5.8 The strtok function, all of the language is about "The first
> >call in the sequence" and "subsequent calls"; no requirement that
> >these calls happen in the same thread is made.
>
> I suspect that this is just an oversight. Surely the intent was not
> to make the existing strtok implementation in Solaris non-compliant
> when threads were introduced in C11.
>
It is function that's broken by design, even without threads. If one
calls any library function while strtok is going and then in later
version of library one decides to also use strtok it will break previous
one.
Only real solution is that people should use strsep or strtok_r instead.