This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: strtok behaviour when uninitialized

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<>  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 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]