csignalライブラリページの追加 #1578
csignalライブラリページの追加 #1578
Conversation
|
⚡ プレビュー (HTML) (更新時刻: 2026-01-21 00:32:05 JST) 変更記事一覧18件の記事が変更されました。
※ソース (.md) に直接変更のあった記事を列挙しています。グローバル修飾や変換規則の変更による変化は考慮していません。 |
|
reference.mdページからのリンクもお願いします |
K10-K10
force-pushed
the
feat/csignal
branch
2 times, most recently
from
ca630e2 to
7bd2348
Compare
reference/csignal/sigabrt.md
Outdated
| ## 概要 | ||
| `abort`関数などによる異常終了時に送られるシグナルの、シグナル番号を表す`int`型のマクロ。 | ||
| 値は正の整数であり、実際の値は処理系定義である。 |
There was a problem hiding this comment.
| 値は正の整数であり、実際の値は処理系定義である。 | |
| `int`型の正の整数の定数式に展開され、実際の値は処理系定義である。 |
There was a problem hiding this comment.
あと処理系定義って何処かに書いてありますか? 処理系定義 (implementation-defined) は「処理系の説明書に値を明記しなければならない」という規格の要求が入ります。もしそういう要求がないのであれば未規定 (unspecified) です。
There was a problem hiding this comment.
C23 7.14 /p4に、
The complete set of signals, their semantics,
and their default handling is implementation-defined;all signal numbers shall be positive.
とあり、値も処理系定義かなと思いました。
cppreferenceにも処理系定義とあったので
There was a problem hiding this comment.
なんか物凄く微妙な記述ですね…。字義通り読むと「どのようなシグナルがその処理系で用意されていてそれぞれどのような意味論を持つか」についてを処理系定義としていて、シグナル番号については単に正と言っているだけに見えますが、何故セミコロンで繋いでいるんでしょうね。。。他にマクロの値もしくはシグナルの番号が implementation defined だと言っている記述はありますか? 今のところ探しても見つけられないでいます。
実用的な観点から言うと、シグナル番号の値が何であってもマクロを通してシグナルを指定している限りは振る舞いに影響はないはずで、そのような内部実装の詳細について処理系定義にする動機がないような気がします。一方で、例えば INT_MAX は implementaion-defined なのですが、これは実際の値がプログラムの動作に影響を与えるので実用的な観点からも処理系定義であって欲しくあります。ここで INT_MAX の規格の記述と SIGABRT などの記述を比較してみるとやっぱり雰囲気が違う気がします。INT_WIDTH が C23 5.2.4.2.1/¶1 で implementation-defined value を持つとされ、C23 5.2.4.2.1/¶3 で INT_MAX は SIGABRT については値が implementation-defined と言っている箇所が今のところ見つけられていなくて、雰囲気これは implemention-defined ではないように感じられます。
cppreferenceにも処理系定義とあったので
cppreference って信頼できるんですかね。
There was a problem hiding this comment.
因みに、MSVC は limits.h の定数は値を明示していますが、signal.h の定数は値を明示していませんね。
一方で、Linux は signal(7) で、FreeBSD は signal(3) で signal.h の定数の値を示していました。とは言っても、このことからは処理系定義なのか未規定なのかについて何とも言えません。未規定は、値を示すことを禁止する訳ではないので。
There was a problem hiding this comment.
実装定義だという記述が見つからなかったので、未規定に変更しました。
この場合(記載がなかった場合)、実装定義か未規定かどうかは、文脈から推測するしかないのですか？
There was a problem hiding this comment.
記載がなかったら未規定だと思っておくと良いです。もっとちゃんと書くと、規格上一つには指定されていなくて、具体的にどうなるか記載がなくて、処理系に任されているのが未規定です。
一方で、"処理系定義 = (未規定 & 文書化要求)" なので、規格の処理系に対する明示的な要求が含意されています。記載がない場合は、特に要求していないということになります。なので、記載がないのに処理系定義と書くと存在しない要求を増やしていることになってしまいます。
わかりにくいかもしれませんが、規格の unspecified/implementation-defined behavior の記述から読み取るのが、一番明確&正確です:
unspecified behavior
behavior, for a well-formed program (3.68) construct and correct data, that depends on the implementation
[Note 1 to entry: The implementation is not required to document which behavior occurs. The range of possible
behaviors is usually delineated by this document. —end note]C23 3.4.4
behavior, that results from the use of an unspecified value, or other behavior upon which this
document provides two or more possibilities and imposes no further requirements on which is
chosen in any instance
Note 1 to entry: J.1 gives an overview over properties of C programs that lead to unspecified behavior.
EXAMPLE An example of unspecified behavior is the order in which the arguments to a function
are evaluated.implementation-defined behavior
behavior, for a well-formed program (3.68) construct and correct data, that depends on the implementation
and that each implementation documentsC23 3.4.1
unspecified behavior where each implementation documents how the choice is made
Note 1 to entry: J.3 gives an overview over properties of C programs that lead to implementation-defined behavior.
というか、もし「処理形依存 = 処理系定義」という認識だったら、そうではなくて寧ろ「処理形依存 = 未規定」です。
| - `_Exit`関数 | ||
| - `quick_exit`関数 | ||
| - `atomic`引数がロックフリーである場合の`<stdatomic.h>`内の関数 | ||
| - 任意の`atomic`引数を持つ`atomic_is_lock_free`関数 |
There was a problem hiding this comment.
C++標準のアトミックライブラリを考慮する必要があるのと、各関数へのリンクを貼る必要がありますね。
C++側でもsignal-safeの仕様がありますのでそちらを確認が必要そうです
There was a problem hiding this comment.
stdatomic.hは、C++としては<atomic>ヘッダと中身がいっしょのようなので、stdatomic.hの話は主にC言語ユーザーに向けた話として書き、C++向けとしては<atomic>側の話を書いた方がよさそうです。
atomic引数というのはアトミック操作するオブジェクトのことだと思いますが、C++だとatomic_refとかの非アトミックオブジェクトを一時的にアトミック操作するものもありますので、追加の事情が必要そうな気がしています
There was a problem hiding this comment.
この部分は #1578 (comment) で書き換えるという話になって、実は既に手元には C23 の記述に従って書き換えた commit があるのですが、一方で C++ の記述も考慮に入れようとすると C と C++ の記述で噛み合ってない部分があってどうしようかなって思ってます。 どうも C++20 C++17 から噛み合っていない様な気がするので、この辺りの変更の経緯を探したら分かるかもしれません (Cの記述を置き換えているのか、C の要求と C++の要求の両方が有効なのか)。
There was a problem hiding this comment.
調べました。
結論から言うと C++17 以降は C 規格の記述は参照せず、C++規格の記述で置き換えるという意図のようです。
詳細: 上で C++20 から噛み合っていないと書きましたが、C++17 からでした。cppreference で記述が "C++17 未満 (until C++17)" と "C++17 以降" で切り替わっていたので C++規格の方で記述が変わったのかなと思いましたが、実際に規格を確認したら違いました (因みに C++20 からと勘違いしたのは until C++17 を C++17 以前と勘違いしたため)。実際は、そもそも C++17 未満ではC++規格側には何も記述がなくて、cppreference は単に C 規格の記述を until C++17 で載せていたのでした。
それで C++17 で signal handler で許される操作についての記述を追加したのは P0270R3: Removing C dependencies from signal handler wording でして、タイトルから分かるように「signal handler の記述についての C への依存をやめよう」というのが P0270R3 の意図です。なので、C規格の記述は無視してそれを置き換える方向ということになります (ただ、規格自体の文面だと、該当の章の末尾に依然として "See also: ISO/IEC 9899:2024, 7.14" と書いて C 規格を参照していて、意図が不明瞭です)。
特に噛み合っていない点として気になっていたのは「C では std::raise/std::abort から呼び出された signal handler では制限がないこと」なのですが、これについても P0270R で何やら言及していまして:
It may make sense to eventually relax these restrictions invoked through an explicit synchronous raise() call. It's unclear that this is important enough to bother.
意訳: 同期的な
raise()経由で signal handler が呼び出された時には、上記の signal handler に対する制限については、最終的には撤廃するのが理に適っているかもしれない。だけどそんな重要かわからないしめんどくさいからいいよね。
というわけで実質 C における制限緩和は C++ ではなくなったつもりで P0270R3 が適用されたことになります。
すみません
レビューお願いします