○[NetBSD] LC_TIME

サブマリンsend-pr急速浮上。 とりあえず海原雄山ＡＡを貼っておこう。

　 　 ＿　□□　　　 ＿　　　　　 ＿＿＿、、、 
　 ／／＿ 　　[][]／／ 　 ,,-―''':::::::::::::::ヽヾヽ':::::/、　　 
／／ 　＼＼　 ／／　 ／::::::::::::::::::::::::::::::i l | l i:::::::ミ　　 
￣　　　　 ￣　 ￣／ /:::::::::,,,-‐,／i/`'''￣￣￣ ｀i::;|　　 
―`―--^--、＿_ 　 /:::::::::=ソ　　 /　ヽ、 ／　　　,,|/　　 これcommitしたの
/f ）,fヽ,-、 　 　 ノ 　|　三　i　<ニ`-, ノ　/、-ニニ' 」'）　 誰だあっ！！ 
　 i'/　/^~i f-iノ 　　|三　彡　t￣ 。` ソ パ゛'、￣。,フ | ）　　　　　　　　 
,,,　　　　 l'ノ　j　 　 ノ::i⌒ヽ;;|　 ￣￣　/ _ヽ、￣ 　゛i　） 
　 ` '' -　　／　　　 ノ::|　ヽミ 　　`＿,(＿　　i＼_　 `i ヽ、　∧ ∧ ∧ ∧ 
　　　　　／／／　　|:::|　( ミ 　 /　＿＿ニ'＿＿｀i　|　　Ｙ　 Ｙ　Ｙ　Ｙ　Ｙ 
　　　,-"　 　 　　 　,|:::ヽ　 ミ 　　/-───―-`l 　|　　／／　 　　 |　　　　 
　　 |　　／／　　 　l::::::::l＼　　　 ||||||||||||||||||||||/　 |　　　　　／／ |　　　 
　　/　　　　 ＿＿__.|:::::::| 　　 、 　`ー-―――┴　/　　　 ＿＿,,..-'|　 
　/゛ー、,-―'''ＸＸＸＸ `''l::,/|　　　　ー- 、＿＿￣＿,,-"、＿,-''XXXXX | 
/XX/ XXXXXXXXXX|　|　　　　　　　　　＿,　　/ノXXXXXXXXXX|

これFreeBSD由来のplain textをlocale databaseにする実装なのよね。
こんな実装でいいならminoura-xpg4dlブランチに同じFreeBSD由来のものがあった訳だし
とっくにmergeされててもおかしくない。
というかせめてmmap(2)使(以下略

tech-userlevelあたりにobjection投げてもいいんだけど、こっちも根拠が弱いんだよね。
一番もっともらしい反対理由としてはlocaledef(1)でcopy directiveの実装に困るってやつ。
↓の話ね。
http://www.haun.org/ml/b-l-j/a/700/739.html
http://www.haun.org/ml/b-l-j/a/700/741.html

とはいっても

• 今回commitされたLC_TIMEの実装だとsymbolic-char情報を持っていないから
  「**コンパイル済みの** 他locale から category 丸ごと持ってくる」
  ようなcopy directiveの実装が無理なのは判るけど、それは今のLC_CTYPEも同様でしょ。
• Linux/glibcのlocaledef(1)も/usr/share/i18n/localeにlocaledef srcをインストールするので
  NetBSDでもそれにならい、copy directiveの実装にはそっちを使えば良いじゃん。
• そもそもISO/IEC TR14652を読むと

  copy "i18n"
  

  とか出てくるし、copy directiveは「**コンパイル済みの** 他locale」ではないんじゃないの？

とでも反論されると弱い。

それとLC_TIMEも広義のメッセージカタログなんだから
C99のinttypes.hで定義されるPRI[dioux](LEAST|FAST)?(8|16|32|64)のようなフォーマット文字(MD部)が
メッセージ文言中に現れる場合、MIで扱わないと/usr/share/locale/*/LC_TIMEとして置けなくなるからマズイ、
とかいっても

• 今のLC_TIMEやnl_langinfo(3)の仕様ではありえない
• じゃあLinux/glibcみたいに/usr/lib/locale/*/LC_TIMEで

とでも反論されると、これまた弱い。

さらにMAGICもバージョン情報もないファイルじゃ後々後方互換で困るかもといっても

• ISO/IEC TR14652ではその手のバージョン情報はLC_IDENTIFICATIONで管理することになってるじゃん

とでも反論されると、さらにこれまた弱い。

さてどうすんべ。

○[NetBSD] localedef(1)

んでちょっと前からISO/IEC TR14652ベースで実装しだして(yamtさんの実装とは全く別)
charmap fileのparseくらいまでは終わってたり。
書きかけのあんまりまだ人に見てもらいたくない状態の ソース。

ちなみにuniversalなcharmapを目指すと私の手に余るので
今のmklocale(3)の作るLC_CTYPEとのフォーマットは変えないつもりで
localedef(1)からencoding moduleをdlopen(3)してruneに変換する手抜き工事の予定だったり。

ISO/IEC TR14652ベースで実装するメリットは

• stateful encoding(ってもISO2022だけだけど)をどうやって扱うか
• wcwidth(3)で返される文字幅をどこで指定するか

など、SUSv3では曖昧だった部分まで仕様が決まってるところ。
まあそれを補って余りあるデメリット(以下略

しかしISO2022周りで 不可解な点がいくつかあってどうしようか悩んでたところだったりする。