C11静的バッファへのポインタを返す関数に対するスレッドの安全性

Question

（歴史的に）静的バッファへのポインタを返すC標準ライブラリのlocaltimeなどの関数を考えてみましょう。 C11はこれらのバッファをスレッドローカルにしますか？

C11で7.1.4パー

：

明示的に以下の詳細な説明では特に断りのない限り、次のようにライブラリ関数は、データ競合を防止しなければならない：ライブラリ関数をスレッドでアクセスできなければならない、直接または間接的にアクセスオブジェクトオブジェクトが関数の引数を介して直接的または間接的にアクセスされない限り、現在のスレッドとは別のものです。ライブラリ関数は、オブジェクトが関数の非const引数を介して直接的または間接的にアクセスされない限り、現在のスレッド以外のスレッドがアクセスできるオブジェクトを直接的または間接的に変更してはならない。実装は、オブジェクトがユーザーには表示されず、データ競合から保護されている場合は、スレッド間で独自の内部オブジェクトを共有できます。

たとえば、localtimeと考えてください。返り値が指すstruct tmは、呼び出し側がアクセスできるので "内部オブジェクト"とは見なされないため、別のスレッドでlocaltimeを呼び出すと、前のスレッドで返された結果が壊れていないようです。これは、localtimeが各スレッドに異なるバッファを使用する必要があることを意味します。

しかし、標準では、アドレスが返されるオブジェクトの存続期間の終わりを指定していません。なぜなら、呼び出し元のスレッドが終了した後でこのプログラムを引き続き使用する理由がないからです。したがって、オブジェクトはスレッド記憶期間を有することができない。

実装がすべての要件を満たすことができる唯一の方法は、意図したとおりではない場所にメモリをリークさせることです。明らかに何かが欠落しているのですか、レガシーインターフェイスに関してC11がthread-safetyを扱っているのですか？

Answer 1

... unless explicitly stated otherwise：7.27.3 Time conversion functionsの序文の章では、これらの機能がデータ競合を回避しないと明示的に述べています。

競合条件を避けるために設計された標準付属書Kの境界チェック拡張には、_s接尾辞付きの派生関数があります。