This is the mail archive of the
mailing list for the glibc project.
Re: strtok behaviour when uninitialized
On Mon, Feb 19, 2018 at 11:31:11AM +0100, Florian Weimer wrote:
> 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<firstname.lastname@example.org> 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
> >220.127.116.11 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.
For what it's worth I think it was already non-POSIX-compliant, since
POSIX has the same language.
Note that there are a number of other interfaces with similar but
worse issues -- where an implementor might want to use thread-local
storage but can't because it's permissible for the application to
continue to access the object pointed to by the return value after the
thread that made the call exited. (Think localtime, gmtime,
localeconv, ....) At least with strtok there is no way this issue
could arise because the application cannot see the thread-local state,
only the results of the call. As such I see a change to the standard
for strtok as more reasonable, whereas a change for these other
functions would be dangerous and potentially-breaking.
> I will try to figure out how to raise a defect report.