strtok behaviour when uninitialized

[Florian Weimer]

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