[debian-devel 00337] Re: glibcのsleep()の実装は安全か?

[Mitsutoshi NAKANO]

2020年2月16日(日) 17:46 KISE Hiroshi <kise ＠ fuyuneko.jp>:
>
> debian-develは、Debian自体の開発(Debianでの開発、ではなく)の話題を
> 扱うところですので、debian-usersメーリングリストのほうが、
> まだ適切かと。
>
> Debian限定でもないですから、Linux関連の話題を扱っているところが
> もっとよいでしょうね。

glibcやカーネルの実装やCの仕様に詳しい方の知見をいただきたかったのですが、
確かにここは適切な場とは言いがたかったですね。反省いたします。

> From: Mitsutoshi NAKANO <itsango ＠ gmail.com>
> Subject: [debian-devel 00335] glibcのsleep()の実装は安全か?
> Date: Sat, 15 Feb 2020 20:58:08 +0900
> > __nanosleep()の2引数に同じアドレスを与えても、問題ないのでしょうか?
> > 例えばstrcpy(s, s)と同じsを与えたら未定義の動作になりますよね。
> > 同じような問題が__nanosleep()で起きたりしないのでしょうか?
>
> そこでstrcpy()と比較するのは、何か違う気がしますが…。

Cの仕様も気になったのでJIS X 3010:2003を一通り読み返してみました。
中野は当初以下の様に勘違いしていました。
Cでは、関数の２引数に与えたオブジェクトの領域が重なりあい、
かつそのオブジェクトに更新があるときは、その動作は未定義となる。

しかしX 3030を読み返したところ、そのような規定はなさそうで、
標準ライブラリ関数については、各関数ごとに領域が重なる場合の動作が規定されていました。
strcpy(), memcpy()は未定義、memmove()は領域を別途確保するので安全であると。
要は__nanosleep()のさらに奥にあるシステムコールが
オブジェクトをどう扱っているかにかかっているのだと解釈しました。
お騒がせしました。