This is the mail archive of the
mailing list for the glibc project.
Re: strtok behaviour when uninitialized
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
18.104.22.168 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