Re: strtok behaviour when uninitialized

[Florian Weimer <fweimer at redhat dot com>]

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.

I will try to figure out how to raise a defect report.

Thanks,
Florian