Re: strtok behaviour when uninitialized

[Rich Felker <dalias at libc dot org>]

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.

If you want to lobby WG14 to change this and allow thread-local state,
I believe this has precedent and thus perhaps support from Microsoft's
implementation, which is grossly non-conforming in many ways, and I
wouldn't be opposed to such a change in the spec. But I don't think
it's reasonable to make a nonconforming change unilaterally and
contrary to the spec. I'd also support (actually, I'd be much more
supportive of) an effort to mark strtok obsolescent in the next
version of the C standard and have it removed in the following
version.

Rich