C++20に採択されたchar8_t型を追加する提案の不可解な点

Question

P0482R5: char8_t: A type for UTF-8 characters and strings (Revision 5)

がC++20に採択され、めでたくchar8_tが標準入りしたわけですが、このP0482R5によくわからない点があります。

Changes since P0482R4の節に

Updated [depr.locale.category] and [depr.fs.path.factory] with changes suggested by Tim Song to ensure behavior remains unchanged.

とあり、なぜかcodecvt<char16_t, char8_t, mbstate_t>, codecvt<char32_t, char8_t, mbstate_t>, codecvt_byname<char16_t, char8_t, mbstate_t>, codecvt_byname<char32_t, char8_t, mbstate_t>が追加されています。

codecvtはエラーハンドリングがガバのプーさんだから消すねっ！ということでC++17で多くが、残っていたcodecvt<char16_t, char, mbstate_t>, codecvt<char32_t, char, mbstate_t>, codecvt_byname<char16_t, char, mbstate_t>, codecvt_byname<char32_t, char, mbstate_t>もC++20でdeprecatedになったことで完全にcodecvtは空気になったと認識していたのですが、
これはUnicode間の変換がガバガバなまま復活を遂げたと理解すればいいのでしょうか・・・？

Comments

[y_waiwai]

で、しつもんはなんでしょうか？

[yumetodo]

これはUnicode間の変換が可能になるということを意味するのか、そうならC++17でUnicode間の変換をdeprecatedにした理由であるセキュリティとエラーハンドリングの問題は解決したのか、そうでないならこの追加の意味は何を示すのか？
ですね

Answer 1

セキュリティ要件を理由としている P0618R0 Deprecating <codecvt> 採択後の C++17標準ライブラリ仕様でも、codecvt<char16/32_t, char, mbstate_t>, codecvt_byname<char16/32_t, char, mbstate_t> という特殊化は有効です。つまりこの時点では「UTF-8 ⇔ UTF-16/32エンコーディング変換は問題ない（少なくとも非推奨化する理由はない）」という合意形成があった（今もある）と思われます。

C++17 [locale.codecvt]/paragraph 3より引用します（下線部は回答者による強調）：

The specializations required in Table 69 (25.3.1.1.1) convert the implementation-defined native character set. codecvt<char, char, mbstate_t> implements a degenerate conversion; it does not convert at all. The specialization codecvt<char16_t, char, mbstate_t> converts between the UTF-16 and UTF-8 encoding forms, and the specialization codecvt <char32_t, char, mbstate_t> converts between the UTF-32 and UTF-8 encoding forms. codecvt<wchar_t, char, mbstate_t> converts between the native character sets for narrow and wide characters. Specializations on mbstate_t perform conversion between encodings known to the library implementer. Other encodings can be converted by specializing on a user-defined stateT type. Objects of type stateT can contain any state that is useful to communicate to or from the specialized do_in or do_out members.

---

P0482R0 char8_t: A type for UTF-8 characters and strings の目的は「UTF-8を表現するchar8_t型の導入」ですから、単にこの趣旨に沿った調整（char→char8_t置換）を行っただけではないでしょうか？

Comments

[yumetodo]

P0618R0では不正なUTFベクトル攻撃へのエラーハンドリング手段がないことを問題視されていたと思うのですが、codecvt<char16/32_t, char, mbstate_t>, codecvt_byname<char16/32_t, char, mbstate_t>ではその問題がない、ということなのでしょうか・・・？

[yohhoy]

オリジナルNB Comment GB-57、採択議事録をあたってはみましたが、そのあたりの細かいニュアンスまでは言及が無い気がします。
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0488r0.pdf
P0488R0 WG21 Working paper: NB Comments, ISO/IEC CD 14882
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4654.pdf
N4654 WG21 2017-02 Kona Minutes

不正なUTFベクトル攻撃云々は、Unicode⇔他文字コード変換に関するリスクなのかもしれません。これ以上のソースは見つけられませんでした。

[yumetodo]

うーん
https://groups.google.com/a/isocpp.org/forum/#!forum/std-discussion
に投げたら回答くると思います・・・？

[yohhoy]

誰かは回答してくれるかもしれませんね。私自身はたまーにしか眺めないので雰囲気をしりません...

FYI: WG21にUnicodeサブグループ(SG16)なるものもあるようです。こちらも探してみてはいかがでしょう。
https://github.com/sg16-unicode/sg16-meetings/