Barbarism begins at internet:2008年05月分

2008/05/01(Thu)

[NetBSD] multi-locale その3

setlocale(LC_ALL, NULL)のmulti-locale版はquerylocale(3)使えってことか。

4.99.62にしたらpthreadまわりのトラブル解消。

[NetBSD] multi-locale その4

うーみゅ、MB_CUR_MAX_L(locale)どうしよ。

[public header]

typedef struct {
    int mb_cur_max_l;
    char __private[1]; /* XXX */
} *_locale_t;

#define MB_CUR_MAX_L(locale) ((locale)->mb_cur_max_l)

[private header]

typedef struct {
    ...
} _locale_impl_t;

static __inline _locale_impl_t *
to_locale_impl(_locale_t locale)
{
    return (_locale_impl_t *)(void *)&locale->__private[0];
}

あるいは

[public header]

typedef struct _locale_impl_t _locale_impl_t;
typedef _locale_impl_t *_locale_t;

__BEGIN_DECLS
int _mb_cur_max_l(_locale_t);
__END_DECLS

#define MB_CUR_MAX_L(locale) _mb_cur_max_l(locale)

[private header]

typedef struct {
    ...
} _locale_impl_t;

とするかの2択なんだが、前者だとopaque objectである_locale_tを

_locale_t x;
sizeof(*x);

とかしてもエラー(dereferencing pointer to incomplete type)にならないので嫌だし
後者だとそもそもマクロにする意味って何よという疑問がフツ族と。

そもそもMB_CUR_MAXがマクロになってる理由が判らん>>C90。

extern int __mb_cur_max;
#define MB_CUR_MAX __mb_cur_max

...

MB_CUR_MAX = 0;

みたいに書換可能な実装されると困るわけだし(今のNetBSDの実装はこれ)。

仕様では

{MB_CUR_MAX}
    Integer expression whose value is the maximum number of bytes
    in a character specified by the current locale.

とあるので、どっちでも構わんのだろけど。

2008/05/02(Fri)

multi-locale (intermission)

いつ見てもSolarisの/usr/include/sys/lc_core.hはよくぞここまで
つかここまでやる必要あるんかちゅーくらい鬼気迫るCSI実装だよな、カコイイ。

まあところどころEUC hardwired wchar_tな SysV MNLS仕様との辻褄合わせ的な部分があるのもご愛嬌。
viとかlibcursesでもwchar_tの空きビットを勝手に再利用してたりするせいで移植性がなかったりするしな。

Traditional viもUCS4 hardwired wchar_tを想定して、32bit目を勝手に再利用してたりして
歴史ってのは繰り返すモンテスキュー。
ちなみにwchar_tの32bit目が空いてないロケールはNetBSDの場合zh_CN.GB18030くらいなので
ja_JP.eucJPとかだと動いてるように見えるけどね。
あ、でも同梱のregex(3)がUTF-8前提なので検索がダメだった記憶がある。

そいやviといえば、nvi-m17nの も絶賛放置中だったな。

nvi-m17nは要望の多いutf-8サポートとかまで考えると結構メンドいので手を出すのに腰がひけちゃうんだよな。
内部コードがISO-2022なので、ESC % GとESC % @のUTF-8モード切替を実装すりゃいいんだろけど
そもそも対応してる端末が皆無に近い、知ってる限りではjfbtermだけだし。
# あれ?xtermってどうだったっけ?

そうすっとset displayencoding=utf-8とかになるんだけど、そもそも今のmulti_*の実装は
コード変換についてはShift_JIS <-> eucJPのように算術計算で可能なレベルしか
ないので、UTF-8のようにテーブルが必要になるんで結構しんどい作業。

今ならiconv(3)に任せるという手もあるのだけど、ISO-2022完全実装とかCTEXTを
サポートしているiconv(3)って、Citrusくらいしかないのよね *1
それでも 前も書いた通り、iconv("CTEXT", "UTF-8")の場合CJK Unified Ideographがあるから
言語タグなり異体字セレクタなりをiconv(3)レベルでも実装してやらんとならん。

現状デファクトであるGNU libiconvがISO-2022完全実装とかCTEXTに対応するとはとても思えんしなぁ。
#そもそもeucJP-MSすら(以下略)

iconv(3)が対応してないから多言語化=Multilingalization=m17nの看板下ろしますとか
内部コードISO-2022やめてUTF-8にしますとか(ソレナンテemacs/mule)するくらいなら
vimでも使っとけという話になっちゃうのよな。

他にもISO-2022 regex関係も、UTF-8モード対応は大変だろうし
今の実装でにある「異なる文字集合を跨いだ検索ができない」制限事項も
fileencoding=iso-2022 inputencoding=utf-8なんかの時、我慢できなくなりそな予感がする。

ほんとは内部ISO-2022じゃなしに内部CSI化がいいのだろな。
iconv(3)使って{file, display, input} encodingからcurrent codesetに、またその逆に変換すりゃいいわけだ。

multi-localeを使えばもっと柔軟な対応も可能だろう。

まあでもm17nの看板は使えなくなるなぁ、ja_JP.CTEXT localeなんてアレなものがあるのはNetBSDだけ *2だしなぁ。
ja_JP.CTEXTがないならja_JP.UTF-8を食べればいいじゃないとマリーアントワNetBSD(以下略
とも思うのだが、既存のISO-2022なファイルが開けなくなる互換性問題もあるし。

つーわけでlocaleベースでの実装はとっとと諦めて、multi_*をcitrus_*で置き換えるのが現実解かもね。
まあ現時点ではregexなど機能が足りてないし、アプリ組込で使う目的には整備されてないので
遠い未来の話だけども。

そいやnviをm17nlibのM-Text化とかする人がまだ出てこない不思議。
あれもそのうちヘッダだけ読んどこうと思いつつサボってるなぁ。

*1:ってもUTF-8モードまではさすがに未実装。
いちおうitojunさんはwchar_tの32bit目をUCS4用にリザーブしておられましたが。

*2:CitrusをmergeしてるDragonFlyBSDでも、MB_LEN_MAX=6の関係で有効になってない。

2008/05/05(Mon)

[NetBSD] ThinkPad s30

ここんとこずーっとアク禁で某スレ書き込めんのでこっち書いとくか。
ThinkPad s30のSiliconmotion Lynx3DMは、Linuxなんかだと

Option "NoUseBIOS"

だけで動くらしいのだけども、NetBSDとOpenBSDのバヤイ

Option "NoMTRR"

も必要だったとオモタ、あるいはkernel configからoption MTRRを消すか。

ちなみにXFree86のお家騒動の真っ最中
Xを終了してVTに落ちると真っ黒けっけというバグがあったのだけど
これxorgに分裂した後も、両者とも長いこと壊れたまんまだった。
XFree86の方は4.5.0ではいつのまにやら直ってるのだけど
xorgでも直ってるかはインスコしたことないので知らない。

連休

天気が微妙 & 指定席取れない ので諏訪参りは後日ということで、ねこゴメン(泣)。

Solarisを起動するとなくなってしまったcat(1)が突然現れた!
ってスタニスワフ・レムかよ。
タルコフスキーのDVDまだ封も切らずに放置中。

パリ、テキサス原宿、戸塚にあるウイトリッヒの森ぶらぶら。
いつの間にかここに住んでたドイツ の技術は世界一ィィィィ人技師の洋館で使われてた
西洋瓦を敷いた休憩所が取り壊されてた。
■年前はホタルが棲むくらい水が湧いてたのだけど、今はサッパリ。
上の老人ホームが水脈切っちまったか。

原宿 A-B-B-B(渋谷区)
原宿 A-B-A-E(戸塚区)

鉞ヶ淵市民の森公園ぶらぶら。
運良くリスの夫婦見れたけど、突然の出現だったのでカメラ向ける間も無し。

戸塚駅西口再開発地域。
旧商店街を縄張りにしてたネコが工事で行き場がないらしく
家一軒分くらいの空き地に20匹くらいが所在なさげにしてて
コレナンテ難民キャンプ状態、ネコの生活も楽じゃない。

2008/05/07(Wed)

[NetBSD] 続 ThinkPad s30

某スレにリンク貼って頂いた方、ありがとうございます。
やっぱVT真っ黒け問題はxorgだと直ってないのね。

続き。
ThinkPad s30でNetBSDを起動する場合、ACPIを有効にしないと
PCIBIOSの方でPCI_*_FIXUPを入れてても一部のデバイスが動かなかった記憶が。
(cardbusだったかusbだったか…ちょっとそこまでは思い出せない)
ただ、3.0とかの頃そうだったというだけで今でも同じ状態かは判りません。

ACPI有効にしてもS3 sleepは復帰後液晶が真っ白けになります。
もしかしたらjoerg氏が作業してるVGA_POST
http://mail-index.netbsd.org/port-i386/2008/01/31/msg000154.html
をどうにかすると上手くいくのかもしれないけど(試したことはないけど)。

あとpiixpcib(4)じゃなくてpcibの方を使わないと
vga_is_console()で刺さる現象が未だ直ってないかもしれないです。
GENERICなら別件(kern/35313)で無効になってるから問題にならないけど。
どうしてもpiixpcib(4)でmachdep.speedstep使いたいなら(そもそもまともに動いてるか知らんけど)
vesafb(4)を有効にすると落ちるとこまで進まないので回避可能。
まあでもアクセラレーションがない? のですんごく遅いですが。

あ、あとvesafb(4)を有効にする場合 options VESAFB_PM を入れてしまうと
液晶のバックライトが消灯したままキーイベントでも復帰しないので
(一度外部ディスプレイに切替して戻せば再点灯する)外しておくのが吉。

それとauich(4)は昔(3.99.??)は音出てたはずなんだけど、今の-currentだとダメ。
何度も分解してボロボロのマシンなのでハード壊した可能性が高いし
原因については深く追求してないです(使ってないし)。
もしそっちでも同じ現象ならsend-prしてあげてください。

連休オワタ

写美エライ、 映画「Control」アンコール上映だってさ。
この勢いでAnton Corbijn写真展も是非お願いしたい。

Anton Corbijnは自身のモノクロ写真でもベース色を black/brown/blueの3色を使い分けてるんだけど
この映画でもシーンによって色を変えてるんだよね、何らかの意図があると思うんだけど
2回見ただけじゃ判らんかった、DVD待ちだな。

「シュルレアリスムと写真 痙攣する美」「知られざる鬼才 マリオ・ジャコメッリ展」も
ちょっぴり見たかったので恵比寿いってくるかと思ったら、どっちも5/6で終わりだったのか orz

Factory Girlどしよかな、映画館までいって見る価値あるかな。
なんとなーくガーリー(笑)でスイーツ(笑)な某マリーアント(ry臭が漂ってくるのだが。

そいやちょっと前にVelvet UndergroundのCDを買い直したら
Murder Misteryもライナーにちゃんと歌詞が載ってて(しかもL-R両方)爆笑した。
John Cale時代のアバンギャルドもDoug Yule時代のレイドバックも
どちらも愛してこそVelvet Undergroundファンですお。

Emulator X3出るのな、やっとこさの64bitバイナリ化なのだが
対応OSにWindows XP x64 editionがないという俺オワタ悪寒。
まあ日本だとCreativeのやる気の無さで、バンドル版のみの販売で
その上あっというまに在庫切れ→販売終了ちゅー忍耐力を試される製品だから
アップデートも初代Xからじゃあダメポな予感がしてきた。

2008/05/08(Thu)

[NetBSD] current-users

確かにsetlocale(3)のBUGSの記述は判りづらい(つかwrapped upの意味が俺にもよく判らん)。
だがそれ以上に質問者にとって何が問題なのかも同じくらい判らんw
せめてPythonのコードくらいは晒して欲しいにゃ。

今日

・cock-up

  1. ぴんと立つ
  2. しくじる(軍隊用語)

撃鉄を起こすが失敗の意味って、男ってやつぁ万国共通(ry

Robert Burnsって"Cock Up Your Beaver"なんてPMRCが卒倒しそうな詩書いてるのね。
「蛍の光」原曲とはもの凄い落差ざますこと。

Cock Up Toe = 鉤爪趾変形
ならば Cock In T(以下略

マオイスト

2008/05/09(Fri)

[NetBSD] strtol(3)

先日 ちょと触れたstrtol(3)ファミリーとISO-2022問題。
仕様書読み返すと、vfprintf(3)の方はmultibyte stateについての言及があるのだけど
strtol(3)の方には一切ないんだよな、先頭をisspace(3)使ってスッ飛ばせとあるだけ。
つまり7bit locking-shiftなstateful encodingの場合 *1、escape sequenceに注意するのは
全て使う側の責任ということっぽいですな。

あとNetBSDのstrtol(3)のソースコメントには

/*
 * Convert a string to a long integer.
 *
 * Ignores `locale' stuff.  Assumes that the upper and lower case
 * alphabets and digits are each contiguous.
 */
long
strtol(nptr, endptr, base)
{

とあって

122 		if (isdigit(c))
123 			c -= '0';
124 		else if (isalpha(c))
125 			c -= isupper(c) ? 'A' - 10 : 'a' - 10;
126 		else
127 			break;

の123及び125行目でdigit char/alha charをintegerに変換する際、コードポイントが
連続してると仮定したXXXなコードアルよ、ちゅー注意がある。

元々FreeBSD rune(3)にはdigittoint(3)という関数があり、上記のソースのようにコードポイントが連続してると
仮定せずともテーブルによってdigit charに対応するintegerが検索できるようになってることは 前も書いたとおり。
まあでもこれ、base=16つまり"A(a) to "F(f)"の範囲までしか対応してないので
base=36まで必要なstrtol(3)の内部実装目的にはそのまま使えないのよね。

それと仕様書だと'0' to '9' および 'A' to 'Z' のチェックについては
isdigit(3)とisdigit(3)を使えとは一切書いてなかったりする。
こっちも 前に書いたけど、ロシア語なんかではキリル文字なんかもisalpha(3)にマッチしてしまうはずの
今の実装はマズー、ちゅうかこの部分のコードは

		if (c >= '0' && c <= '9')
			c -= '0';
		else if (c >= 'A' && c <= 'Z')
			c -= 'A' - 10;
		else if (c >= 'a' && c <= 'a')
			c -= 'a' - 10;
		else
			break;

で上手く動かんよな文字コードをlocaleでサポートすることはまず無いのでこれでい(以下略

志高くdigittoint(3)相当を使った方がいいんだろうにゃ。
ただし今のmklocale(1) srcではDIGITな文字には全てTODIGITが宣言されてた記憶があるので
mklocale(1) srcからキリル文字なんかはTODIGITを指定しないよう
修正しなきゃあかんのだけどもさ。
つかlocaledef/charmapだとどうなってんだっけ?考慮されてない悪寒。

ちゅうかTODIGITを再利用しようとすると、LC_CTYPE databaseの後方互換問題が微妙。
/usr/shareに置かれてるので、古いLC_CTYPEと新しいlibcの組み合わせでも
正常に動作する必要がある *2わけですが、なんかfallback用意しとかんとな。
まあフォーマットは変わってないのでshareするときは新しい方使え、でもいいのかも。

Solarisではlc_core.hを見る限り、multi-locale版strtol(3)は用意されてなさげ。
multi-locale版iswctype(3)はあるので、isspace(3)使ってスペース読み飛ばせの部分を考えると
本当は必要なはずんだがね、glibcはstrtol_l(3)がありますな。

げげげFreeBSDってlibcにOpenBSD由来のstrtonum(3)をマージしてんのか、えんがちょ。
OpenBSD方面ではstrtol(3)を使わずstrtonum(3)を使え、なのだけども
これに対する 批判by thorpej氏。
まああえてワシが一言付け加えるならstrtol, strtoll, strtoimaxのよーにinteger typeを使い分けず
long long int決めうちだと性能面にも結構響くよというのがあるけど、theo氏にいわせりゃ
「早いマシン買え」で終わりだろな。

もうちょいまともなインタフェースにブラッシュアップしたとしても
NetBSDならlibcでなくlibutilのefun(3)で扱うレベルの関数っすな。
strlcpy/strlcatと違ってlibcの内部実装でこんなん使う用事はまず無いしってことで。

しかしOpenBSD向けCitrus patchではmulti-localeなstrtonum(3)も用意しなきゃならんの。
嫌すぐる。

個人的にはstrtol(3)については、時々

char *s = "00010002"; /* 4桁ごとに変換したい */
char tmp[5];
long int upper, lower;

strlcpy(&tmp[0], s, sizeof(tmp));
upper = strtol(&tmp[0], NULL, 10);
s + = 4;
strlcpy(&tmp[0], s, sizeof(tmp));
lower = strtol(&tmp[0], NULL, 10);
...

みたいな場合、コピーがかったるいのでlength chekが欲しくなることはある。

つかこの例レベルならsscanf(3)で問題ないか、もっとアレなケースでもfmemopen(3)使って

FILE *fp;
char *s = "00010002"; /* 4桁ごとに変換したい */
long int upper, lower;

fp = fmemopen(s, strlen(n), "r");
fscanf(fp, "%4ld%4ld", &upper, &lower);

と書いた方がいいのかもしれん、しかしfmemopen(3)はまだ標準じゃないのがな。
NetBSDにも無いし(わし書いた実装は ここ) 。

vfscanf(3)自体の%[doux]の実装の為にもlength checkつきstrtol(3)の実装があると
スッキリ書けるような気がしないでもないけど。

strtod(3)だと小数点にLC_NUMERICのdecimal_pointを使うのに
thousands_sepについてはstrtol系は全く対応しないよな。
vfscanf(3)もvfprintf(3)と違って「'」フラグ対応してないので同様。
これはlocaleなんつーものが入ってくる前時代との整合性なのかね。

あとglibc2のvfprintf(3)の%I[doux]も対応するならwctrans table?に追加が必要なのよな。
しかし使ってる実例を全く見たこと無いのでやる気ナッスィング。

C99でstrtoint32()とかstdint.hに入らなかった謎。

*1:まあISO2022-JPなんてlocaleはNetBSDとnewlibとXくらいしかサポートしてませんが。
*2:いちおFreeBSDのLC_CTYPE databaseとの互換性すら考慮して実装されてるからなぁ。
まあFreeBSD 5.0でのフォーマット変更後には対応してないけど。

[Cygwin] nl_langinfo(3)

そのテストsetlocale(3)呼ぶの忘れてますよ。

今のcygwinのnl_langinfo(3)はnewlibレイヤにありますが、これ実装はFreeBSDからパチってきたものです。
ところが元々newlibにあったsetlocale(3)の実装だと、FreeBSDの"ja_JP.SJIS"とは違った形式、つまり
"C-SJIS"というようなidentifierが使われるのですが、それを考慮して書き直しが必要なのに
それを一切やってないっちゅー凶悪なシロモノだったりします。

まあnl_langinfo(3)をnewlib/libc/locale/locale.cので宣言されてる_locale_charset()を
使うように書き直すだけなんですが、newlib peopleはツギハギもまともにできないんだなぁ。

そいとcygwinにリンクされてるnewlibは-U_MB_CAPABLEでbuildされた記憶があるので
setlocale(3)呼んでもC locale以外使えず"US-ASCII"以外は返ってこないと思います。

Cygwinのlocaleまわりは、2ch Unix板の方の「Cygwin使ってる人いますか?」スレの
初代、及びPart4から6あたりの過去ログと、同時期のcygwin-developer MLのアーカイブを
読むと雰囲気掴めるかと。

しかし

な海外勢ってアバウトってレベルじゃねーz NetBSDじゃありえん。

2008/05/10(Sat)

[NetBSD] ThinkPad s30 + piixpcib(4)

うーむpiixpcib(4)で凍るようになっちまってますやね。
r1.15でdevice_t化される前はvesafb(4)でvga_is_console()で落ちるのを
回避すれば動いてたんだけど。

dmesg見る限りspeedstep_configure()まで進んでないのね。
多分vga_is_console()と同件で、どっかでメモリ破壊起きてて
device_private()から壊れたsoftcが返されてしまい
pcibattach()内で落ちてるととりあえず予想してみる。

違った、speedstep_configure()まで動いてて最後、"SpeedStep SMI enabled"を
aprint_verbose_dev()で出力する時、何故かsc->sc_devがNULLになっとるせいで
刺さってる模様、うーむ。

[NetBSD] 続 ThinkPad s30 + piixpcib(4)

piixpcib(4)はattach()時にgenericなpicb(4)のattach()を呼ぶのだけども
piixpcib_softcと src/sys/arch/x86/pci/pcib.cの方のpcib_softcの
構造体って互換性無くなっちまってるな、これが原因臭。

[NetBSD] ThinkPad s30 + piixpcib(4) その3

あんまりキレイなやりかたじゃないけど、いちおpatch。

Index: sys/arch/x86/pci/pcib.c
===================================================================
RCS file: /cvsroot/src/sys/arch/x86/pci/pcib.c,v
retrieving revision 1.4
diff -u -r1.4 pcib.c
--- sys/arch/x86/pci/pcib.c	28 Apr 2008 20:23:40 -0000	1.4
+++ sys/arch/x86/pci/pcib.c	10 May 2008 11:49:53 -0000
@@ -49,6 +49,8 @@
 #include "isa.h"
 
 struct pcib_softc {
+	device_t		sc_dev;
+
 	pci_chipset_tag_t	sc_pc;
 	pcitag_t		sc_tag;
 };
@@ -202,6 +204,7 @@
 	aprint_normal_dev(self, "%s (rev. 0x%02x)\n", devinfo,
 	    PCI_REVISION(pa->pa_class));
 
+	sc->sc_dev = self;
 	sc->sc_pc = pa->pa_pc;
 	sc->sc_tag = pa->pa_tag;
 

本当はpiixpcib.cの方を直すべきなんだろけど。
vga_is_console()で落ちる件も調べた後にでもsend-prすっか。

[NetBSD] ThinkPad s30 + piixpcib(4) その4

vga_is_console問題は再現しなかったのでsend-prしてきた。
でもpiixpcib_softcからpcib_softcへの変換がcastってダサくね?
今回のバグってJavaで書くなら

class A {
   ...
}
class B extend A {
   ...
}

A a;
B b;
a = (A)b;

のように、class A(=pcib)とその派生class B(=piixpcib)という
関係をCで実装するのに

struct A {
    ...
} *a;
struct B {
    ...
} *b;

a = (struct A *)b;

と書いた挙句、仕様変更時にAに追加したメンバを
Bに追加し忘れますた、ちゅーことなのだよね。

やっぱCならこうHAS-Aで書いた方が安全だよな。

struct A {
   ...
} *a;
struct B {
    struct A super;
    ...
} *b;

a = &b->super;
a = (struct A *)b; /* 全くお勧めしないけどこれでも動く */

softc構造体は各bus間ではdevice_tというopaque objectで
実装を隠蔽してるんだけども、piixpcibとpcibは隠蔽するような関係じゃないとオモ。

[NetBSD] multi-locale その5

newlocale(3)のcategory_maskの実装について。

これまでのsetlocale(3)だと

setlocale(LC_ALL, "");
setlocale(LC_CTYPE, "");

のように、全てのカテゴリあるいはどれか1つを指定するのだけど
newlocale(3)では

newlocale(LC_ALL_MASK, "", base);
newlocale(LC_COLLATE_MASK|LC_CTYPE_MASK, "", base);

のようにOR使って細かく指定できるようになったのよな。

んでsetlocale(3)のidentifierって実装依存なのだがNetBSDの場合

$ cat >test.c
#include <locale.h>
#include <stdio.h>
main()
{
    setlocale(LC_ALL, "C/ja_JP.eucJP/C/C/C/C");
    printf("%s\n", setlocale(LC_ALL,  NULL));
}
^D
$ make test
$ ./test
C/ja_JP.eucJP/C/C/C/C

のよに、LC_ALLの場合はスラッシュ区切りで各カテゴリを
設定/表示する仕様なのだけども、multil-localeではORが使えるので

printf("%s\n", querylocale(LC_COLLATE_MASK|LC_CTYPE_MASK, locale));

とかした場合、どういう結果が返るのがいいのかね。

C/ja_JP.eucJP

のよに、指定されたcategoryだけを設定 or 表示すると判りづらいよな。

glibc2の場合はsetlocale(3)のコードを実行すると

LC_CTYPE=ja_JP.eucJP;LC_NUMERIC=C;LC_TIME=C;LC_COLLATE=C;LC_MONETARY=C;LC_MESSAGES=C;LC_PAPER=C;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=C;LC_IDENTIFICATION=C

となるけど、querylocale(3)はglibc2にはにゃいので結果が判らん。

TODO: MacOS Xのquerylocale(3)がどういう結果を返すか、調べに電器屋へいくこと。
うちのDuo230にTiger入んねぇかな。

2008/05/11(Sun)

[i18n] message catalog

悪意のある言語パック

前もちらっと書いたけど、悪意のある翻訳者対策って厄介だよな。
ワシがなんとか理解できる日本語と英語だって、ねこだいすき縦読みにアナグラムに
slangスラングを駆使して一件まともな訳文に見えて、その実まったく別の意味だったりすると
チェック洩れる可能性があるからねぇ。
one-shot translationなんてのはrelengの問題で片付くけど、査読は
信頼できる人間が各言語毎に最低2人はいて、クロスチェックしてもらわんと
ずぇーったい無理だ罠。

週末

雨降ると寒いねぇ。
いつもなら暖をとりに膝に飛び乗ってくる奴がいないのがさみしい。
ネコいないのでベランダに鳩が居座ってグルッポ鳴いてる。

ネコ最後の日の写真が現像上がり。
歩くのもやっとなのに猫草をなんとか口にしようと病に立ち向かう姿。

先日入手したばかりのAF28-75mm/F2.8(D)の後玉に傷つけちまったんで
ソニーのコニミノ修理窓口に送付。

お散歩用カメラにハーフが欲しかったのでOLYMPUS-PEN EEDをげと。
外観わりと綺麗でレンズにファインダーもカビのない個体で
570円は安いよな、まあこの機種はPENの中でも特に人気なさそうだけど。
cdsがちと劣化気味のようでシャッター速度遅い奇ガス、調整必要かもね。

[i18n] message catalog (追記)

悪意のある言語パックというより、汚染された言語パックとゆー話らしい。
まとめ参照。

あと2chの某スレのよーに「翻訳は有害」なんてアレな主張をしてるわけじゃないことに注意。
ソースならC言語に精通してるdeveloperは山ほどいてクロスチェック盛んだけど
翻訳の場合、複数の言語に精通してる人間はこの界隈には数少なく貴重だとゆー話。

CSI xterm

LANG=ja_JP.UTF-8で起動しようとするとBadFontでコケるのか。
/usr/X11R6/lib/X11/locale/ja_JP.eucJP/XLC_LOCALEでのXLC_FONTSETで
指定されてる文字集合は全部XTerm*FontSetに指定してあるのだけど。

RELNOTE-I18N読むとXlib-I18N入れろとあるのだけど、cvs repositoryが消えとる。
昔checkoutして固めといた奴も見当たらん、げげげ。

続 CSI xterm + Xlib-I18N

確かKondara LinuxがXlib-I18Nをmergeしとったっけなと突然思い出すものの
kondara.org見事に消えとるしミラーサイトも消滅しとるな。

rpm searchでXFree86-4.0.2-0.2li18nux.nosrc.rpm ちゅうものをハッケソ。
nosrcかよ!でぐんにょり。

specみるとXlib-I18N-cvs-20010129.tar.bz2ちゅうのがどっかあるはず。
ちかごろはarchie gateway消滅してて世の中退化しちょる。

要はXFree86-4.2.0でXlib-I18Nは完全に統合されたのかどーかをチェックしたいんだが
XFree86のxc/lib/X11/xlibi18nのlog読んでもいまいち要領を得ない。

しゃぁねぇ、真面目にCSI xtermのソース読むか...

2008/05/12(Mon)

[NetBSD] multi-locale その6

glibc2のLC_ALL_MASKって将来的にlocale categoryを追加する場合
ばっちり後方互換が失われる悪寒。

# define LC_ALL_MASK	(LC_CTYPE_MASK \
			 | LC_NUMERIC_MASK \
			 | LC_TIME_MASK \
			 | LC_COLLATE_MASK \
			 | LC_MONETARY_MASK \
			 | LC_MESSAGES_MASK \
			 | LC_PAPER_MASK \
			 | LC_NAME_MASK \
			 | LC_ADDRESS_MASK \
			 | LC_TELEPHONE_MASK \
			 | LC_MEASUREMENT_MASK \
			 | LC_IDENTIFICATION_MASK \
			 )

新しいカテゴリ追加すると、定数値であるLC_ALL_MASKの値が変わってしまうやね。
# まあこれ以上追加する必要ががあるかどーかわ知らん。
あっちはELF symbol versioningあるし気楽なのだろう。

つーわけでこっちの実装は

#define LC_ALL_MASK	((int)~0)

とでもしとくけ。

昨日

OLYMPUS-PEN EEDの試写を兼ねて、そこいらブラブラ。

国立病院の駐車場横の林、リスが突然目の前横切って驚いた。
こんなちょっぴりのスペースで生活していけるのだろうか。

某パチョコン量販店でMacOS X、漢字Talkwwwwを触ったことがある程度なので使い方ワカンネ。
つか普通XCodeなんて店頭にあるマシンにゃ入ってない希ガス。

急に吐き気と眩暈で立ってられなくなる、先々週と同一のバグっぽいので運用で対処。

ねこに仏花買おと思ったらJ( 'ー`)しカーチャンの日トラップで売ってねぇ。
しょうがないのでヤツの生まれ故郷の諏訪の酒買ってお供え。

2008/05/13(Tue)

TODOs

近日中に済ましとけーな作業

昨日

某楽器店、HOHNER Pianet-Tが値下げしてたけど10万円って。
つかオク相場だと5万がいいとこだから当分売れ残りそうだな。

花屋、クリスマス翌日のケーキ屋的様相を呈してた。

人民解放軍が迷彩服を着てるとガッカリする香具師は
Solid State Survivor / YMO 聴いてたオサーン。

ロシア的倒置法、中華人民共和国では 錻力の太鼓 が Japan を叩く!
そうかだから反n(以下略

ギュンター・グラスの小説の方はジャガイモ畑で早々に挫折した俺。

This ain't rock`n'roll, This is DOMESTIC PROBLEM!
    - ``Diamond Dogs'' by David Bowie

出火吐暴威って 珍マシーンTin Machine以降、過去曲封印したままだと思ってたんだが
最近はふつーに演奏ってんのな、ちゅうか VitteleのCM 感動した。

へーVistaの起動音ってRobert Frippなんだ、いーのー。
昔「太陽とシスコはロックシティ & 戦慄」というバンド名を考えたのだがボツ食らった。

2008/05/14(Wed)

昨日

フジ110フィルム終了
Pocket Instamaticってやつだけども、後はコダがいつまで作り続けるかだな。
まぁ Ferraniaもあるけど。

むしろこれの先祖の126フィルム、Instamaticの方が
正方形フォーマットちゅーことで魅力なのだけど
こっちはFerraniaと ADOXが生産してるのみで、日本だと入手困難ですな。

今週末からからドキュメンタリー映画「 JOY DIVISION」っすな、渋谷の初日とか行くと
学生時代のサークルのメンツと遭遇しまくりんぐな予感、回避すっか。
いい年こいてコピバン再結成とかエロ過ぎる。

うちのギターは最近他所でジザメリ直系シューゲイザーバンドをはじめたらすい。
ベンチャーズ直系テケテケバンドをやるのと同じ老化現象ですね、わかります。

中古CDフェア@川崎。
David BowieのRykodisc盤探したのだけど収穫harvestなし。

蜘蛛の名前ならミック・ロンソンだろJK、だがしかし ニール・ヤング
次のバンドは「ニール・ぺ・ヤング & グレイシー柔術」と「黒過ぎーステルス(以下略

カレー臭漂ってまいりますた。

[NetBSD] multi-locale その7

newlocale/duplocale/freelocale/querylocaleの実装中。
やっぱDistributed I18N Frameworkの方が設計まとも。
glibc2はがんばりましょうの判子押してやりてぇ。

2008/05/15(Thu)

[NetBSD] multi-locale その8

querylocale(3)の戻り値は、結局"/"区切りのままにしといた。
uselocale(3)はThread Local Storage必須なのでいまんとこ常時ヌルポ返却。

FreeBSDのlink loaderから

をパチってくるだけの簡単なお仕事です。
素人歓迎、委細面談

MacOS Xの man querylocaleを読むとmaskのbit操作順は
カテゴリ名でalphabetical orderとあるのだが、NetBSD的には
歴史的な事情(LC_MESSAGESが 後から追加された)があるので
あくまで

LC_COLLATE -> LC_CTYPE -> LC_MONETARY -> LC_NUMERIC -> LC_TIME -> LC_MESSAGES

とゆー順序のままにしといた。

これFreeBSDでも 事情は一緒なはずなんだがな、MacOS Xで変更したのだろか。

ちなみに

setlocale(LC_ALL, "");
setlocale(LC_ALL, NULL);

以外、つまり

setlocale(LC_ALL, "ja_JP.eucJP");
setlocale(LC_ALL, "Japanese_Japan.932");

とか環境変数LC_ALLを使わずに、直接idを指定した場合
そのソースコードは移植性無いのだけども、multi-localeを使う場合ってのは
当然環境変数とは異なるidを指定したい訳で、OSごとにifdefするなり
設定ファイルに追い出すなりの仕掛けが必要になっちまうのよな。
これは非常にめんどい。

いちお LI18NUX Locale Name Guidelineとして実装依存ではなく共通化する動きはあったけど
非Linux方面にはサクっと無視された記憶。
ところでNetBSDでlocale名のloose matchingを実装して欲しい人いるんかな。

あと これ、 idの先頭が/だった場合はpathnameとするなんて仕様もあったのか。
とりあえず放置。

根本的にPOSIX localeの設計自体が筋悪なのだよな。
カテゴリごとに別々のlocaleをセット可能とか。

なんて場合は

LC_CTYPE=ja_JP.eucJP
LC_TIME=C
export LC_CTYPE LC_TIME

とするのだけど、本来これはmulti-localeで処理すべきことなのよな。

なもんで、今の仕様だと

LC_CTYPE=ru_SU.KOI8-R
LC_COLLATE=ja_JP.eucJP
export LC_CTYPE LC_COLLATE

ソヴィエトロシアでは日本語がロシア語のソート順を規定する!
LC_CTYPEがru_SU.KOI8-Rなので、wchar_tの内部表現はKOI8-Rなのに
wchar_tの内部表現がeucJPであることを仮定したcollation order logicが動くという
アレなことになってしまう。

Javaなんかは後発なだけあって当初からmulti-locale設計なのだが
java.util.Localeにはカテゴリなんて概念はなくて 物知りモノリシックなわけだし。

Java(TM)ではjava.text.*FormatしてからSystem.out.printlnする!
理由のひとつはmulti-localeなのだが、Java5では
java.io.PrintStream.printf()なんてぐんにょりするの入ったくらいだし
仕様決めてる人たちももういろいろ忘れてるんだろう、糖衣構文マンセー。

Cの場合、文字列は自身の文字コード情報を持ってないので(JavaはUTF-16 hardwired char)
文字列とlocale_tの組み合わせはユーザ管理になるから非常にややこしいのが難点。
その一点だけはCERT Managed String(=string_m)のembedded locale info羨ましい。

話戻して、POSIX localeのの筋の悪さを考慮しないままmulti-locale化しようとしてるのは
TOG(=Distributed I18N Framework)もglibc2(=Thead Aware Locale Extension)も
一緒なんだが、LC_*_MASKとか導入して更なるgdgdを呼び込む後者の方が度し難い。

昨日

AIWA終了、逆に考えるんだAIWAがSONYを(以下略
現SONY元コニミノのαボディ設計者は予算が増えて喜んでるらしいけど。
つうかコニミノ時代の製品はどんだけ腹ぺコの中で(以下略

某スレ、やっぱThinkPad s30のauich(4)って-currentだと音出ないのだな。
2chの*BSD/ThinkPadスレ見ると少なくとも2002年までは 音出てたみたいだぬ。

2008/05/16(Fri)

[i18n] setlocale(3) で指定するロケール名の移植性

kbkさんとこ。
setlocale(3)でどうやって

を文字列にして指定するかは、 仕様では決まってないのですよ。

The locale argument is a pointer to a character string containing the required
setting of category. The contents of this string are implementation-defined.

とある通り、"C", "POSIX", "", NULL以外は実装依存です。

まあUnix方面だと

言語 + "_" + 地域 + "." 文字符号化手法 ( + "@" おまけ)

というフォーマットで

となってる実装が多いのですが
これHTTPのAccept-Languageのように、 RFC4646 Tags for Identifying Languages
の仕様で縛られてる訳ではないです(そもそも言語タグだと"_"じゃなくて"-"ですな)。
混同されてる方は要注意。

さらに文字符号化手法については

と、まあ表記の揺れが激しいわけです、glibc2ではloose matchingとか導入したくらいで。

HTTPのAccept-CharsetはいちおIANA charset registry縛りがあるのだったっけ?
あれはPOSIX localeには何の強制もないですし、そもそも

setlocale(LC_ALL, "ja_JP.Extended_UNIX_Code_Packed_Format_for_Japanese");

なんて嫌すぐる *1

それと、複数のカテゴリをいっぺんにsetlocale(3)に指定する場合も
やりかたは実装によってバラバラです、いくつか確認してみましょ。

Solarisの場合

$ cat >hoge.c
#include <locale.h>
#include <stdio.h>
#if defined(_WIN32)
#define JPLOCALE "Japanese_Japan.932"
#elif defined(__linux__)
#define JPLOCALE "ja_JP.EUC-JP"
#else
#define JPLOCALE "ja_JP.eucJP"
#endif
main(void)
{
	setlocale(LC_ALL, "C");
	setlocale(LC_CTYPE, JPLOCALE);
	printf("%s\n", setlocale(LC_ALL, NULL));	
}
^D
$ make hoge
cc -o hoge hoge.c
$ ./hoge
/ja_JP.eucJP/C/C/C/C/C

各カテゴリをスラッシュ区切りで表示します(順序はLC_*の定数値の小さい方から)。
なのですが、"/"ではじまる場合はpathnameと解釈するちゅう仕様に反してる気が。
つかそもそもスラッシュ区切りだと、LC_ALLの場合pathnameが使えなくなりますな。

/usr/local/share/locale/ww_WW.wwwWW/LC_COLLATE;/usr/local/share/locale/ww_WW.wwwWW/LC_CTYPE;...

とか、せめて;とか:なんかにしとけばよかったのに。

glibc2の場合は

$ ./hoge
LC_CTYPE=ja_JP.EUC-JP;LC_NUMERIC=C;...

となります、これはこれでウザい(注:単に個人差です)。

われらがNetBSDは↓になってます、FreeBSDが4.4BSD runeを拡張したコードが元ネタ。

$ ./hoge
C/ja_JP.eucJP/C/C/C/C

Solarisと似てますが、先頭が"/"ではじまる場合はpathnameと解釈するPOSIX仕様とはいちお整合性あります。
まあLC_ALLの場合pathname使えないのはSolarisと一緒です(汗)。

んで最後、MSVCはglibc2と一緒っすね。

C:\> hoge.exe
LC_COLLATE=C;LC_CTYPE=Japanese_Japan.932;...

んで気づいてしまったのだけど これ、将来的にカテゴリを追加する( ISO/IEC TR 14652にはある)
場合を考えると、カテゴリが足りない場合エラーになる今のNetBSD setlocale(3)の
実装では glibc2のLC_*_MASK問題と同様に、やっぱりバイナリの後方互換性失われるのよなぁ。
仕様にopaqueとは書かれてないので、移植性を諦めさえすれば
ハードコードすることは別に禁じられてないし…うーむ頭痛い。
どーせ互換性無くなるならglibc2/MSVC風の方がキモイけどリーズナブル。

この問題の別解として

setlocale(LC_ALL, "ja_JP.eucJP");

として、LC_ALLを指定した場合は全部同じロケールをセットすること以外は
禁止してしまえばいいようにも思えるのだけど

char *tmp, *s;

setlocale(LC_ALL, "C");
setlocale(LC_CTYPE, "ja_JP.eucJP");
...
tmp = setlocale(LC_ALL, NULL);
s = strdup(tmp); /* save current locale */
...
setlocale(LC_ALL, s); /* restore previous locale */
free(s);

というcurrent localeのsave/restoreを行うコードが動作しなくなっちまうよな。

まあアプリ側はそもそも この通り

そもそも、/ で区切る指定ができるということを POSIX その他は
全く規定していないですし、そういうことをやりたい人は LC_xxx で
明示的に指定するべきでしょう。

なのよな。

つーわけでパラノイアなアプリ実装者は、とことん安全側に倒して

char *tmp, *collate, *ctype, ...;

setlocale(LC_ALL, "C");
setlocale(LC_CTYPE, "ja_JP.eucJP");
...
tmp = setlocale(LC_COLLATE, NULL);
collate = strdup(tmp); /* save current LC_COLLATE */
tmp = setlocale(LC_CTYPE, NULL);
ctype = strdup(tmp); /* save current LC_CTYPE */
...

setlocale(LC_COLLATE, collate); /* restore previous LC_COLLATE */
setlocale(LC_CTYPE, ctype); /* restore previous LC_CTYPE */
free(collate);
free(ctype);
...

とした方がいいかもしれない、save/restore目的にはLC_ALLは使うなと。
ああ、やっぱりPOSIX localeは設計が腐(以下略

あと XFree86/xorg のlocale.aliasにある

POSIX-UTF2                                      C

なんじゃこれ(UTF2ってのはUTF-8の古い名前ね)。

いちお ではC/POSIX localeのnl_langinfo(CODESET)がUTF-8でも構わない *2のだけど
XFree86/xorgがこのaliasをつけちゃうのは、あんまりよろしくない。

*1:NetBSDの場合、実装の都合上ロケール名は32byteまでだったり。
*2:これ、えんがちょの理由はUTF-8だからではなく、わざわざUCS2までの限定サポートにしてること。

[NetBSD] multi-locale その9

uselocale(3)、Thread Local Storage無しでもerrnoみたいにlibpthread側で実装すりゃいいのだが
そもそもC++(=libstdc++)のmulti-localeを使いもんになるようにしよーぜ
ちゅー消極的な目的の為だけににlibpthreadなんぞ弄りたくないんだよな。
でもsrc/gnu/dist/gcc4/libstdc++-v3/config/locale/gnu以下をgrepするとワラワラと。
よく読んでない(読みたくない)けど、__gnu_cxx::__uselocale使えば逃げられるのかな。

それにしてもC++0xはもはやなにがなんだかワカンネ。
0xは200x年の意味じゃなくて、 エクストリームな気がしてきた。

2008/05/17(Sat)

[NetBSD] nvi-1.81.6

src/dist/nvi なんて入ったな、Berkley DB 3だかのライセンス問題は
dist行きにすることで回避ちゅうことか。

まだimportされただけなので、相変わらず/usr/bin/viは1.79。
なのでpkgsrc/editors/nviの方を入れてみる。
したらpkgsrc/editors/nvi-m17nが上書きされてもた、CONFLICT指定要るな。

1.81.6はwcurses使うって事はCSIなのね。
UTF-8のテキスト編集するにはLANG=ja_JP.UTF-8で
xtermとnvi起動すりゃいいんだけど
うちのCSI xtermはUTF-8ロケールでBadFontでコケる件解決してないんだな。

とりあえずja_JP.eucJPロケールで動かしてみる。
なんかカーソル位置が変だなこりゃ。
wcursesが悪いのかnviが悪いのか、端末側の問題ではないっぽ。

debian openssl problem

ディルバートwwwワロタ。

以前NetBSDでも Covertyで指摘されたcvs(1)のメモリリーク問題を 修正した時
エンバグして壊したなそういや、まあ大したバグじゃないけど。
bin/34030参照。

こういうツールでないと発見できないようなリークはイコール
人がパッと読んで指摘できないリークなわけで、要は パスタ(笑)スパゲッティなのですよ。
下手に直してエンバグするよりは放置した方がマシだったってケースは
私のよに最下流SIで生きてると何度もあって骨身に染みるという。

とかいいながらbin/34030で俺もエンバグさせてるんだけど、どんだけwww

ツールは便利だし積極的に使うべきなんだけど *1
これは古墳の壁のここにカビ生えてますよ、って教えてくれるだけ。
カビが今後どのように成長するかとか、補修の可否までは教えてくれないってこと。
下手うてば当然高松塚(以下略

*1:フィクションですが、株価低迷で自社株買い走ってもなお下がるなら
Covertyでも買ってすこしは品質を上げて、ユーザから怒られる回数を
減らした方がなんぼかマシだとおも。

[NetBSD] 続 nvi-1.81.6

LANG=ja_JP.ISO2022-JPで動かねぇ *1

common/conv.cあたりをチラ読みすると、iconv_open(3)に"WCHAR_T"とか
アレな指定してるみたいなんだが、いつものGNU libiconvが正義パターン?
まいった、こんなんならTraditional viの方がまだマシだ…

*1:XFree86だとlocale not supported by Xlibになるので、ja_JP.ISO-2022-JPを
/usr/share/locale/locale.aliasに追加すべし。

[NetBSD] pkgsrc/x11/gtk2

gtk-query-immodules-2.0、非UTF-8なmultibyte localeでmemory fault。
「UTF-8!出た!UTF-8出た!得意技!UTF-8出た!UTF-8!これ!UTF-8出たよ~~!」
俺は限界だと思った。

2008/05/18(Sun)

週末

元横浜ドリームランド跡地の 俣野公園ぶらぶら。

うまいこと遊園地時代のケヤキやクスノキを残したもんだ。
おかげでずーと古くからある公園のようでとても落ち着く。
横浜市環境創造局GJ、いや単に野球場に取られて予算がないのかもしれんが。

敷地の半分は墓地、当初は根強い反対があったみたいだけど
完成してみると広い芝生に小さな墓銘碑がならぶ洋風の墓園で、明るく違和感がない。
寺が狭い敷地に日本式のあの威圧感ばりばりのおどろおどろしい墓石を
所狭しと並べる時代はもう終わりでいいとオモタ。

春日神社の鹿と遊ぶ、公園が整備されたんだし奈良みたいに放し飼いもいいな
...と思ったが、鹿せんべいは飲物ですが何か? ちゅー旺盛な食欲に恐怖。
樹木が全部やられてしまうので無理ですな。

横浜薬科大の裏を抜けて山を下る、このへんはゴミが非常に多い。
元々遊園地とゲーセンちゅーアドレナリン系施設だったしな。
樹木豊かな公園のよなチルアウト系施設に変わったことで落差が目立つ。

俣野神社、建物はボロボロでコレナンテ物置状態なのだけど
境内の横浜市指定名木古木の大もみじがイイ、涼しい。

やっぱり体調が悪いので寝込む、台風来たら起き上がれない悪寒。

[NetBSD] src/lib/libc/locale/localeio.c

あーもウンザリ、雄山AA貼る気力もない。
file magicすらないPlain Textでdb作って将来的に仕様変更あった場合
libcの後方互換で困るとかそういうこと少しは考えようぜ。
/usr/lib/localeなら別にいつでもフォーマット変更できるけど
/usr/share/localeは将来見据えて設計するだろ、JK。
libcのmajor crunkしようが永遠に逃げられないんだからさ。

まあ最悪libcのmajor crunkした上で

ちゅーkludgeかまして逃げる道もあるけどさ、それしないのがNetBSDじゃねの?

まじでlocaledef(1)のcopy directiveの実装どうする気だろう。

気なのだろか。

あ、あとgettext(3)とLC_MESSAGESの競合問題もあったな。
LinuxだとLC_MESSAGES/SYS_LC_MESSAGESですやな。

[NetBSD] share/locale

ISCII-DEVとかiconvがサポートしてねぇcodeset突っ込むなよ。
FreeBSDから持ってくるだけでいいなら
NetBSDのlibcの上にFreeBSDのlibc上書きしてcommitすりゃいいよ、もう。

[C言語] 複数のlocaleをスッドレ毎に切り替える

kbkさんとこ。
ここ最近私がちまちま実装してるmulti-localeの話がまさにそれで
Ulrich Drepper氏は門前払いどころか Thread-Aware Locale Extensionちゅうドラフト書いてて
こいつは Linux Standard Baseにすでに取り込まれてます、なのでglibc2では

#define __USE_GNU
#include <locale.h>
#include <xlocale.h>
#include <wchar.h>

main(void)
{
    locale_t eucjploc, utf8loc;
    char eucjp[3] = "\xa4\a2";
    char utf8[4] = "\xe3\x81\x81";
    wchar_t eucjpwc, utf8wc;
    mbstate_t eucjpst, utf8st;
    size_t neucjp, nutf8;

    eucjploc = newlocale(LC_ALL_MASK, "ja_JP.eucJP", NULL);
    utf8loc = newlocale(LC_ALL_MASK, "ja_JP.UTF-8", NULL);

    mbrtowc_l(NULL, NULL, 0, &eucjpst, eucjploc);
    mbrtowc_l(NULL, NULL, 0, &utf8st, utf8loc);

    neucjp = mbrtowc_l(&eucjpwc, (const char *)&eucjp[0], sizeof(eucjp), &eucjpst, eucjploc);
    nutf8 = mbrtowc_l(&utf8wc, (const char *)&utf8[0], sizeof(utf8), &utf8st, utf8loc);
}

ちゅーコードが書けます、他にもMacOS X、MSVC8にはもう実装されてるようです。
...しかし同時にmbstate_tとlocale_tを管理しないとならないのは非常にウザい、センスに欠け(ry

当然これらはC標準ではないし、POSIXですらありませんので移植性は×です。
一度POSIXのAustin Groupでproposedされたのですがなぜかwithdrawnされてますね。
ISO/IECでも、C1Xに入れようという話はまだ出てないと思います。

というわけで言語標準でmulti-localeしたいならC++使いましょう、って
libstdc++はこのThread-Aware Locale Extension依存なのですけども ;-<

2008/05/19(Mon)

src/lib/libc/locale/localeio.c その2

CHAR_BIT != 8 のarchでshare/locale以下が互換性無いから
全部backoutしろとtech-userlevel投げたら流石に荒れるだろうなwww
どうみても数字な職業の方のいいがかりレベルです。

2008/05/20(Tue)

[NetBSD] multi-locale その10

とりあえず

まで 動くようにしてみた、まだまだ先は長いのう。

stream系methodはとりあえず

  1. singlebyte locale版
  2. multibyte locale版

の2つをlibc側に実装してsetlocale(3)で切替るくらいでヘタレてみる。
本来はencoding module側に持たせちまった方がいいんだろうけど
どっちみちencoding moduleのsoname変えないために
btowc/wctobの時にやったようにfallbackが必要になるわけで
そんだったらlibc側で実装しちまえという。
んでstatelessの場合にstatefulを意識したコードが性能落としそうなら
multibyte系を更に分割ってことで。

めんどくさいのはvfprintf(3)とvfscanf(3)だな。
まあvfprintf(3)については以前書いて放置してた 実装があるので
こいつの#ifdef NOLOCALEとしてある部分を少し修正すればいいのだが
なんせ新規にスクラッチの実装なんで、テストケースを大量に用意して
chiristos氏の持ってきたFreeBSDの実装と差換えた場合にエンバグしないことを
確認しなければならないのが非常にめんどくさくてやる気にならんのよな。
いちおうglibc2から借りてきたtestcaseは動いてた記憶があるのだけど
さすがにんなもんsrc/regressには突っ込めんし、なきゃないで危険だし。

そもそもこの実装ではformat stringのparseをvfprintf(1)とvfscanf(1)で
template header化しよとしてたんだけど、あまりメリットなかったんでヤメるべ。
他にも実装を始めた当初は

printf("うは%1$lc%1$lc%1$lc%1$lc%1$lcおぇ%1$lc%1$lc%1$lc%1$lc%1$lc\n", L'w');

のような場合、wcrtomb(3)の変換結果をキャッシュして使い回すことで高速化しようと思ったのだけど
width/precisionが絡んだ場合、コードがやたら複雑になったのでそこも捨ててしまった。
#そもそもpositional orderが指定されてない時は逆に性能落ちそうだし。

突然{Free,DragonFly}BSDのsys/linker_set.h相当が欲しくなってきたような気がする。

CSI xterm + Xlib-I18N その3

wizpyでおなじみのTurboLinuxってATOK X + IIIMFだったっけと思い出して
XFree86-4.1.0-20.001.src.rpmをばらしてみたら
中からXlib-i18n-xf4_1-200108007.tar.gzをハッケソ、IYH。

2008/05/21(Wed)

昨日

ねこ月命日、もう一ヶ月か。
まだ押入の中で目を光らせてるような気がするし
歩くときもしっぽ踏んで怒られないよに擦り足になってしまう。
でも天敵が去ったことを察した四十雀がベランダに巣を作り出した。
やっぱりもういないんだよな。

明けて今日は創立記念日?(よく知らない)で会社休み。

遊行寺そばの諏訪神社。

藤沢、江の電。

七里が浜、もう夏近いね(梅雨まだです)。
護岸に腰掛けて、J・G・バラード読んでた。
変態だー(AA略

トンビかっけ、ちょーかっけぇ。

2008/05/22(Thu)

[NetBSD] multi-locale その11

とりあえずmulti-locale版vfprintf/vfscanfは後回し、ちゅうか放置し過ぎて仕様忘れた。
strtol系でも先にやるか、こっちについては
'0' - 'Z'(=digit char) -> 0 - 35(=integer) 変換用の情報を_RuneLocaleに追加が必要、と。

RuneTypeのTODIGITマスクを使いまわすのヤメ。

ちゅー理由にょり決めた、strtol系は性能じゅーよー。

strtod系どうすっかな、gdtoaは鬼門だからな。

今日

風邪までひいてもた、さくらんぼ緑茶の匂いが全く判らん。

ThinkPad s30お前もかで調子悪い、キーがいくつか押しても効かない。
これは箱の中で放置されてるX61のたーたーりーじゃー。
しょうがないのでThinkPad 240起動(ぉ

c-users.jpというドメインを取得してfree/malloc論争を
永遠に続ける夢を見




ませんでした。

それ以上に興味無いんだけど今更FizzBuzz問題、真っ先に

/*
 * fizzbuzz_runtime.c
 *    this code is automatically generated by:
 *        fizzbuzz_codegen version 1.0
 *    DO NOT EDIT MANUALY!
 */
#include <stdio.h>
main(void)
{
	puts("12Fizz4BuzzFizz78FizzBuzz11Fizz1314FizzBuzz...");
}

というコードを考えた俺。

fizzbuzz_codegenの中身なんぞ好きにして、なんだが

#!/bin/sh

cat <<FIZZBUZZ
/*
 * fizzbuzz_runtime.c
 *    this code is automatically generated by:
 *        fizzbuzz_codegen version 1.0
 *    DO NOT EDIT MANUALY!
 */
#include <stdio.h>
main(void)
{
	puts("12Fizz4BuzzFizz78FizzBuzz11Fizz1314FizzBuzz...");
}
FIZZBUZZ

さすがにこんなん納品されてきたら泣く。

2008/05/23(Fri)

今日

tech-userlevelに例の件 英誤投げといた
localedef(1)は spec then code というより spec then buy code だたな、いぇーUNIX(TM)!!

libcの前方 後円墳及び後方互換性について、これまで機会がある度に 書いてきたけども
libcが読み込むファイルフォーマットってやつが実は一番頭が痛い。

まあファイル名が変更可能なら構わんのだが、/etc/master.passwdとか
変更するのは憚られるものについては致命的な影響がある。
正直file magicとversionをつけたところで迂闊に変更できるものじゃないんだな。

今日は風邪引いてげろげろな体調なのでまた後日書く予定。

multi-locale、strtol系のドンガラだけ 突っ込んだ、とても酷いマクロですね。
こういうcpp(1)使ってtemplate紛いの事をするよりは、ほんとはPerl Template-Toolkitなどで
各型に合わせたソースを自動生成するほうが好きだったりするけど。

2008/05/24(Sat)

[NetBSD] tech-userlevel

長文書くとこれまた 長文返ってきてまた長文書かねばならない負のスパイラル。
めんどくさいから週明けてから返事書くかもしれない *1

localedefのcopy instructionについて、都合のいい解釈し杉だな。
確かにlocale dbにsymbol-name情報持つのは無駄なのだけどもね。
なので私は

/usr/share/locale/*/LC_CTYPE/
    localedb.1
    localedefdb.1
    charmapdb.1

てな感じで別ファイルとして持つ気でいたのだよ、libcはlocaledb.1だけ読むと。
んでcharmapdb.1はiconv(3)でも使えるようなフォーマットで、ってな感じで。

げ、Solarisのlocaledefについて/usr/lib/localeじゃなくて
/usr/share/localeとか間違ったpath書いちまった。
でもSolarisはlocaledefのソースじゃなくてinstall済みのdbを見てるとしか思えん。
コード読んでないけど(CDDLだしな)

charmap "PCK"
LC_TIME
copy "ja_JP.eucJP"
END LC_TIME

とした場合、truss(1)の出力ではja_JP.eucJPのencoding module中のmbtowc相当が呼ばれてるようなので
multibyte(eucJP) -> wchar_t(eucJP) -> ? -> wchar_t(PCK) -> multibyte(PCK)
という動きをしてる気がする、つまり実質内部でiconv(3)が動いてるのと
同等(前おいらも同じこと 考えた)だと想像してるのだけども、誰か解析してくれんかな。

まあこの方法だと両者が異なるCCS(Coded Character Set)である場合
変換できなくなる可能性があるのだが、 以前書いたように
CCSが異なる場合そもそもlocaledef srcなんて共有デキッコナイス!なはずなので
これでもいいのかも知れん。

あと少なくともglibcはLC_{MONETARY,NUMERIC,TIME,MESSAGES}を保持する構造体について
string版だけでなくwide string版を持ってた記憶があるのだが
あれはdb読んだ後on the flyで作ってるのかそれともdbにもストアしてるのかどっちだっけな。
あれあると便利なんだけど。

今のlocaledef仕様ならISO/IEC TR14652どまりの運命で今後変わらんだろうけど
Unicode.orgがやってるLDMLなんかに今後置き換えられない保証ってないよな。

あたりで攻めようと思ってるのだが、最後のは2chの 詭弁のガイドラインに抵触しかねんな。

というかワタシャ当時developerじゃなかったんで知らんのだけど
minoura-xpg4dl枝をmergeした時、LC_CTYPE以外(まあLC_COLLATEは論外だが)
をmergeしなかった事について、何かコンセンサス残ってないのかな。

いまのPOSIX localeやlocaledefの仕様がいかにダメダメかは
実際にzWとかHZとかISO-2022とかUTF-7とかUTF-5/6とかイレギュラーな
CES(Character Encoding Scheme)についての知識がないと判らんだろな。
あれを持って考えられてるというなら"角度とか"だな、やるおのキリッAA貼りたくなる。
そんなの無視しろという意見もあるだろーけど、わたしゃ根っからの 構造主義者なので受け入れ難い。
What's so funny about Peace Love & Understanding/by Elvis Costello
だけど相互理解ってのは放置プレイが基本だよ。

*1:今 猫にかまけて/ 町田康 を読みながら涙と鼻水垂らすのに忙しいかんね。
うちのねこと老猫ココアがそっくり過ぎてもうダメ。

2008/05/25(Sun)

[NetBSD] localeio

もう本気で返事書くのまんどくさい。

そもそもfile magicなしのdb fileなんてのは
国士無双13面待ちテンパイを崩してフリテン単騎待ちにするような
ピーのやることなんだが、あンた背中が煤けてるぜといわれちゃ
説得のしようがない、それでも100%ツモるならおメエの強運をワシに(以下略

まあginsbach氏には大筋でmagic付与なりLC_*のdirectory化には
同意して貰えたように思えるが、誰が結論を出して作業すんだ。
いまーちNetBSDの決定プロセスというものがいまだにnewbie気分のおらには判らん。
まあ某所に参加してないからなんだろけど、そんな時間は無いパートタイマーの悲劇。

んでNo kiddingとまでえらいいわれ様の"spec then buy code"なlocaledefについて。
stateful encodingについての仕様がmbrtowcにきっちりあるのに
どう逆立ちしてもlocking shiftを表現できないlocaledefの仕様、そして
ISO-2022-KR他のすでに存在するCESでテストされたとはとても思えない ISO/IEC TR14652
の拡張なんぞ擁護する必要はないんだよ、と夜回り先生のように言ってあげたい。

copyの仕様について。
http://www.opengroup.org/onlinepubs/000095399/utilities/localedef.html

the copy statement names a valid, existing locale, then localedef shall
behave as if the source definition had contained a valid category source
definition for the named locale.

まあこの文だけ読むとインスト済みの``compiled'' LC_*がソースとして
振る舞うと読めますな。

ややこしいのは

charmap "UTF-8"
LC_MESSAGES
copy "ja_JP.eucJP"
END LC_MESSAGES

と valid locale nameを指定するとあるのだけども
ISO/IEC WG15 POSIXで配布していたlocaledef srcのサンプル(今はリンク切れ *1)には

charmap "UTF-8"
LC_MESSAGES
copy "ja_JP"
END LC_MESSAGES

となてて、valid locale nameではにゃい。

これをUI-OSF日本語実装規約などにあるとおり
ja_JPはja_JP.eucJPのaliasとして扱う、つまり実質
copy "ja_JP.eucJP"と同じと考えればまぁ矛盾無いんだけどね。

しかーし元々localedefってのはCSI思想のものとして生まれてるんで
localedef/charmapの分離はeucJPとUTF-8といった実際のCESとは関係無しに
同じものが使うという思想の元に生まれてる。

localedef -f ja_JP -i eucJP ja_JP.eucJP
localedef -f ja_JP -i UTF8 ja_JP.UTF-8

つまりこんな感じで、ja_JPというlocaledef srcは共有すべしという思想。
つまりcopy "ja_JP"はbinaryでなくsourceを要求してるのではないかという
疑惑があるわけだ。

閑話、このPOSIXで配ってたlocaledef srcには

comment_char %
...
<%> /x25

とbrace中にcomment_charが出現した場合非comment_charとして扱わないと
アレな記述があるのだが、これ仕様にあるのだろうか。

閑話休題、更にISO/IEC TR14652で g11nに妄執するUnicoderの影響から

LC_CTYPE
copy "i18n"
END LC_CTYPE

と更にカオスになってるのよ、お前setlocale(LC_ALL, "i18n")って何の冗談だ。
世界でたったひとつのロケール wr_WR.UTF-8(笑)?
せんせー、ここにお花畑で全体主義で帝国主義者なひとがいまーす!!
明らかにこの時点でcopyはcpp(1)によるincludeレベルにまで堕落してるのな。

ちなみにglibc2はwchar_t=UCS4なので/usr/share/i18n/localedef/i18nが実在する。

まあ 以前書いたとおり完全なlocale nameは未定義だかんね、何でもありだけど。

んで、わたくしめとしてはこの混乱をどう解釈したかってーと

ちゅーかんじ。

これを英語で書こうとすると確実に丸1日以上潰れるわけで、んな時間あるなら
写真撮りに行きたい鍵盤とかベースとかギター弾きたいCD聴きたいコード書きたいよ、ほんま。

以前lib/10877がcommitされたときにきっちり説明しとくべきだった。
バオバブの芽の抜き忘れって怖い。

*1:私はダウソ済みなのだけど再配布ってライセンス問題無いのだろうか

昨日

散歩中に雨に降られたのでコンビニでビニール傘を買う。
最近のビニール傘は骨が接着剤なので、強風下だと5分持たずに
破壊されてしまうし買いたくなかったのだけどしょうがない。
悪貨は良貨を駆逐する、国家総GM病。

本屋の書籍検索コーナー、隣の人が検索してるキーワードで吹いた。
最初に[セイシ]、次に[セイショク]、うわー中学生かよと思ってつい観察してしまったのだが
最後に[セイショクノイシ]、生殖の意思? すわカーンチ、セクロ(以下略
答は"聖燭の碑"。俺が中学生でした orz

花屋、ガーベラ飽きたのでバラ。
そいや大船の県立植物園のバラは今が見頃かな。

2008/05/26(Mon)

週末

熱下がらん。

普通の会社だと健保が薬箱くれると思うんだけど
今の会社一度も貰ったことねーなそういや。

寝てもらんないんで外出。

近所の広場で顔見知りのネコ(元野良で今は首輪付き)に出会う。
普段は警戒心バリバリでさーっさと逃げられてしまうんだけど
今日は珍しいことに目の前でゴローンして無防備、春だからな。

久しぶりに触れたネコの感触、火葬場で最後にうちのネコを抱きしめた感触。
"さよならとは少しの間死ぬことだ"ってチャンドラーだっけ? うまいことゆうね。

げろげろしつつゆうげの買物、黒猫のラベルのシャンパン。
青い瓶の色が子供の頃つけてた首輪の色と同じなのが気に入った。
そこらにあったPaul Smithの包装用リボンを誰かが結わえてただけなんだけど。

うちの子はいわゆる錆柄なのだが(だったのだが)、家にやってきた時は
全身真っ黒で下顎と首の下だけが白い、まるでツキノワグマの様な子ネコだった。

身体が大きくなるにつれ、ぼんやりと茶が交じり出したのだけども
すっかり黒柄だと思い込んてた私は、その事に気付いて仰天した。

というのも数日前、食器の茶渋落としの為にシンクに水と漂白剤を張っていたから。
この子は器用だしもしかして転落防止用の板を押し退け、漂白剤の中をざぶんと
水泳したんじゃないかと心配してしまったのよね。

そんな出来事のあったアパートの数十メートル先に
わりと全国でも有名な酒倉があった、今遺影の前にはそこの日本酒が供えてある。
お世辞にも美味い酒とはいえんが。

線香を1本焚いて、買ってきたシャンパンと交換し封を切る。
ヤツがこの世に生を受け、目も開かぬうちに捨てられてた土地の水の酒。
自分としても人生最低の2年間を過ごした場所で、思い出したくない事ばかりなのだけど。

ちなみに拾ってきてくれた姐さんの名前は神さん、本当に神様でした。
ありがとう、そしてもっと長生きさせてあげられずに申し訳ない。

そして酔っ払いが出来上がって一人下らん文章を書いている、ばくはつしちまえ。

こんなん拾った、Blue Monday / by New Orderでも聴いて寝る。
         ,i':r"      `ミ;;,;;,
         | ̄ ̄月曜日 ̄ ̄)
         ;! ̄ ̄ ̄ ̄ ̄ ̄~;;;!
          ,ゞi" ̄ フ‐! ̄~~|-ゞ,
         ヾi `ー‐'、 ,ゝ--、' 〉;r'
         `,|  / "ii" ヽ  |ノ
          't ト‐=‐ァ  /  おまえら、もうすぐ月曜日くるから。
        ,____/ヽ`ニニ´/   よかったなあ。月曜日くるぞ月曜日
     r'"ヽ   t、     /
    / 、、i    ヽ__,,/
    / ヽノ  j ,   j |ヽ
    |⌒`'、__ / /   /r  |

[NetBSD] shared library with -lc その2

lib/37827がclosedになたけど、libcが常に最後にリンクされるよー対策されたんかな。
されてなきゃとっても楽しい事になりそだが。
この話ね、まあ Linuxでは実現してるのでさすがにそんなアレなことにはならんと思うが。

orz だめじゃん。

ldd /usr/bin/vi
/usr/bin/vi:
	-lc.12 => /usr/lib/libc.so.12
	-lcurses.6 => /usr/lib/libcurses.6

libcが最初にlinkされんので-stdc=c90とかだと壊れんぞ、これ。
それともld_elf.soに仕掛け入ってる?ちょっとテストしてみないとなぁ。

これで駄目だったらuserlandなめこすなって感じ。

まあC99の関数などで現状weakになてるものは問題ないので
それを逆手にとって全部漏れなくweakにして逃げるちゅー手段もあるけどな。

あと依存関係記録するならglibc2よろしくld_elf.soもやっといたほうがいい。
もしglibc2を馬鹿にしてる人がいたらやめた方がいい、彼らはいろいろ経験から学んでる *1
私にとっては常に学ばせていただく相手だ(CSI派としては学んでほしくもあるがw)。

*1:wchar_t=UCS4もありゃ判っててやってる本来の意味でないほうの確信犯だしな。

[NetBSD] localeio

メールまだ書いてないが上の件もメール書かないとならなくなるかもんがーーーーーーーー
まじで憂鬱な月曜日。

2008/05/27(Tue)

[NetBSD] shared library with -lc その3

昨日の続き、なんか対策してあって問題ないみたいね。
よかったよかった。

$ cat > foo.h
extern void mbrtowc(void);
^D

$ cat > foo.c
#include <stdio.h>
#include "foo.h"
/*
 * in gcc -std=c89 environment,
 * we can freely use c95 symbol, mbrtowc
 */
void
mbrtowc(void)
{
	printf("hello, world.\n");
}
^D

$ gcc -std=c89 -shared -Wl,-soname,libfoo.so.0 -o libfoo.so.0.0
$ ln -sf libfoo.so.0.0 libfoo.so.0
$ ln -sf libfoo.so.0 libfoo.so
$ ldd libfoo.so.0.0
libfoo.so.0.0:
	-lc.12 => /usr/lib/libc.so.12

$ cat > bar.c
#include "foo.h"
main(void)
{
	mbrtowc();
}
^D

$ gcc -stdc=c89 -Wl,-rpath,. -I. -L. -lfoo -o bar bar.c
$ ldd bar
bar:
	-lc.12 => /usr/lib/libc.so.12
	-lfoo.0 => ./libfoo.so.0
$ ./bar
hello, world.

ちなみに明示的に-lcをつけると当然のことながらコケる。

$ rm -f bar
$ gcc -stdc=c89 -Wl,-rpath,. -I. -L. -lc -lfoo -o bar bar.c
$ ldd bar
bar:
	-lc.12 => /usr/lib/libc.so.12
	-lfoo.0 => ./libfoo.so.0
$ ./bar
[1]    Segmantation fault (core dumped) ./bar

objdump(1)してDynamic Sectionを見ると

Dynamic Section:
  NEEDED      libfoo.so.0
  NEEDED      libc.so.12

とちゃんとlibfoo -> libcの順になってんのね。

でもldd(1)のこの表示は極めて心臓に悪いwwwww
objdump(1)のNEEDEDと同じ順で表示するようにしてホシス。

[NetBSD] localeio しょの3

何とかメール書けたのでもうちょい推敲してから投げるか。
今度もすごい長文、もうやだ。
まあ睡眠不足で今日はもうバタンキューしそうな予感がしてるけど。

基本路線としては

ってとこ、あとはlocaledef(1)の実装についての私のアイデアをグダグダ書いてみた。

投げた。 かゆうま。

[NetBSD] {str,wcs}to{f,d,ld} with "0x"

この件について、ある方 *1よりgdtoa本家の方でpatchが提供されてるという情報をメールで戴きました。
どうも有難うございます。

http://www.netlib.org/fp/changes

Sat Mar 15 11:44:31 MDT 2008
  dtoa.c and gdtoa.tgz:  with -DINFNAN_CHECK and without
-DGDOTA_NON_PEDANTIC_NANCHECK, conform to the ill-advised prescription
in the C99 standard of consuming (...)  in "nan(...)"  even when ...
is not of the expected form.  Allow an optional 0x or 0X to precede
the string of hex digits in the expected form of ... .
  gdtoa.tgz: gethex.c: have, e.g., strtod("0xyz",&se) set se to "xyz".
Previously it was incorrectly set to "0xyz".

正しくこれのようです、ちょっと手元で試した上でしかるべき筋に話してみますね。
でもgdtoa担当のkleink氏最近まったく見ないよなぁ。

うーstrtol系の方もpatch書き直してテストケース書かないとな。

*1:えーPR出す時、お名前出していいですかね? :)

2008/05/28(Wed)

[NetBSD] {str,wcs}to{f,d,ld} with "0x" しょの2

いちおgdtoaのバグについては、以前wcstodを直したときに テスト書いてあるから気が楽だ。
今#if defined(__NetBSD__)してる部分消して通ればおk。

見返してみるとstrtodの"0x"バグってglibc2にもあるのな、完全に忘れてた。
テストケースが豊富なglibc2には珍しいやね。

multi-locale化はgdtoa弄らんとならんのだが3rd Partyなのでめんどいよな。

とおもたら-DUSE_LOCALEなんてあるけどナニコレ。

すでにlocaleconv()対応してあるね、こいつを*_l化すんのと
hd_init.cで作成してるhex -> digit変換テーブルを_RuneLocaleで持てばよさげ。

2008/05/29(Thu)

[NetBSD] shared library with -lc しょの4

ふーん、NetBSDはld.elf_so(1)にLD_TRACE_LOADED_OBJECTS環境変数が実装されてない *1のね。
だもんでldd(1)は自前でELF headerを解析してるちゅーことだ。
http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.bin/ldd/ldd_elf/ldd.c

static void
print_needed(Obj_Entry *obj, const char *fmt1, const char *fmt2)
{
	const Needed_Entry *needed;

	for (needed = obj->needed; needed != NULL; needed = needed->next) {
		const char *libname = obj->strtab + needed->name;

		if (needed->obj != NULL) {
                        print_needed(needed->obj, fmt1, fmt2);
                        if (!needed->obj->printed) {
                                fmtprint(libname, needed->obj, fmt1, fmt2);
                                needed->obj->printed = 1;
                        }
                } else {
                        fmtprint(libname, needed->obj, fmt1, fmt2);
                }
        }
}

んでldd(1)の結果と実際のld.elf_soの処理順が一致してないちゅーバグがあると。

Linuxだとldd(1)はbash scriptだし、FreeBSD/OpenBSDはCで書かれてるけど
どれもこれもLD_TRACE_LOADED_OBJECTSをセットしてfork(2)してるだけやね。

それとld.elf_soって .init/.finiの実行順が腐ってたのを 最近直したのか。
そもそも この話はlibc major crunkが発端だったのだけど、いつの間にか
ELF Dynamic Flagsの使い方の話にも進展してたんだ、へぇ。

ちゅーわけでNetBSDならlogin.confに

defaults:\
	:setenv=LD_TRACE_LOADED_OBJECTS=1:\
...

とか書いても何ともないぜ(やめなさい

*1:どーりで/usr/pkg/emul/linux/usr/bin/lddにNetBSDバイナリ食わせると
ただのlauncherとして動作するわけだわwww

[NetBSD] multi-locale その12

catopen(3)のmulti-locale化、それ自体は簡単な作業なんだが
そもそもgencat(1)の吐くmessage catalogsってMIだったっけ?ちゅうのがあるよな。
昔のSun gettext(3) + msgfmt(1)にはPRI*マクロなんか使うとMD問題があるので
GNU gettext(3)ではformat変更までしてMI対策した記憶があるのだけど。

まあサポートしてないならないでprintf(3)のformatには使うな
とでもマヌアルにのCAVEATSにでも書いときゃいいんだが。
今更そんなこというなという噂もある。

ちなみにPRId32マクロ

#include <stdint.h>
int
main(void)
{
        printf("%"PRId64"\n", 0);
}

をxgettext(1)使ってぶっこ抜くと

msgid "%<PRId32>\n"
msgstr ""

ちゅー感じになる。

あとLC_MESSAGES=ja とかlanguageだけ指定してる場合のケアどうすっかだな。

gettext(3)はmo catalogのヘッダにcharset埋め込んで
iconv(3)で変換とかそれってどうよ?な事やってるんだけど、format変わっちまうしな。

単純にケアしない、もしくはlocale.aliasでja -> ja_JP.eucJPへのaliasを貼るでいいよな。

2008/05/30(Fri)

[NetBSD] multi-locale その13

catopen(3)は/usr/share/nls/nls.alias使うんだっけか、すっかり忘れてた。

HP-UXのマヌアル読んでると、xgettext(1)に相当するコマンドのfindmsg(1)は
PRIマクロ対応してるとあるのだけども、どうやら単純にcpp(1)を前段にカマしてるだけっぽ。

よろしい ならばMDだ。

まいや、multi-locale化の対象から一端はずしておこう。
そもそもglibc2とかMacOS Xにはcatopen_lは無いしね。

前書いたvfprintfのコード見直し中。

NetBSDのFILEって__SALCフラグなんちゅーのがあって
こいつでopen_memstream(3)相当の処理が可能だったのな、邪悪だ。
なんでこんなのが導入されたかってと、vswprintf(3)の実装の為なんだけども。
まあ邪悪さでいえばsnprintf_ss用に追加された__SAFE最凶、さすがに削除されたのね。

しかしSolaris10のsnprintf(3)の マニュアル 読むと

sprintf() 関数と snprintf() 関数は、「非同期シグナル安全」です

はてはてどんな魔法を使っていることやら。

昨日

おされ居酒屋の飯は常に不味い事を証明する為の集い、じゃなくて現場の飲み会。

ウン国際宇宙ステーションのトイレ、乗員が自分らで 修理完了だと。
Gene Kranz率いるTiger Teamが"Failure Is Not an Option"を合言葉に
ステーション内にある限られた材料から これ作るシーンを想像して吹いた。