This is the mail archive of the
mailing list for the glibc project.
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<email@example.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
188.8.131.52 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.