The Man Who Fell From The Wrong Side Of The Sky:2008年10月分

2008/10/1(Wed)

[NetBSD] __link_set_* vs lint(1)

__link_set_add_*だけで使われるよなstatic symbolに対してlintがエラー出すので困る。

$ cat >test.c
#include <sys/cdefs.h>

__link_set_decl(foo, int);

static int x = 0;

__link_set_add_data(foo, x);
^D
$ lint test.c
test.c:
test.c(5): warning: static variable x unused [226]
Lint pass2:

まぁこれだけなら

#include <sys/cdefs.h>

__link_set_decl(foo, int);

#ifndef __lint__
static
#endif
int x = 0;

__link_set_add_data(foo, x);

ちゅうふうに、事前定義マクロ__lint__で逃げてもいいのだが、こんどは

hoge multiply defined ... test1.c?(75)  ::  test2.c?(75)
hoge multiply defined ... test1.c?(75)  ::  test3.c?(75)

と__lint__のバヤイは、staticじゃなくなるから同名のsymbolがあると
multiply definedの警告にハマる罠、げげげげ。

これcdefs*.hでなんとか回避できんのかな。
__RENAMEマクロで使ってる__symbolrenameのよに、lint(1)自体手を入れないと
無理だとするとまんどくさくてやっとれんのだが。

きゃー(笑)

2008/10/2(Thu)

Linux/glibc2のld.so(1)はシンボルのウィーク属性(STB_WEAK)を無視する

以前書いた「 ウィークシンボルって何ですか?」のエントリについて
メールを頂きましたので、そのお返事おば。

メールから引用。

さて、サンプルを試していて気づいたのですが、weak symbol についての下の部分で、
Fedora8 (glibc-2.7)ではこの通りにはなりませんでした。

>$ ln -sf libconflict1.so.0 libconflict1.so
>$ gcc -Wl,-rpath=. -L . -lconflict1 -lconflict2 -o test_conflict test_confict.c
>$ nm test_conflict | grep b[au][rz]
>        U bar
>        U buz
>$ ./test_conflict
>i'm conflict1::bar!
>i'm conflict2::buz!

その代わり、LD_DYNAMIC_WEAK をセットして実行するとうまく行きました。

$ /lib/libc.so.6
GNU C Library stable release version 2.7, by Roland McGrath et al.
...
$ LD_DEBUG=symbols ./test_conflict
...
    4808:     symbol=buz;  lookup in file=./test_conflict [0]
    4808:     symbol=buz;  lookup in file=./libconflict1.so.0 [0]
	<= ここ
i'm conflict1::buz!                      <= ここ
...
$ LD_DYNAMIC_WEAK=1 ./test_conflict
i'm conflict1::bar!
i'm conflict2::buz!

info ld.so の LD_DYNAMIC_WAEK の説明には、glibc の動作を先祖返りさせるという記述があるので、
どこかの時点で、デフォルトの動作が変わったのでしょうか。

    LD_DYNAMIC_WEAK
        (glibc  since  2.1.91)  Allow  weak  symbols  to  be overridden
        (reverting to old glibc behavior).

ごめんなさい、*BSD以外の話がずっぱり抜け落ちていましたね(滝汗
時間のある時にサンプルは静的リンクを使ったものに修正しておきますです。

Linux/glibc2が動的リンク時のweak属性(STB_WEAK)の挙動を変更した理由は
このメールでUlrich Drepper氏が至極あっさりと説明しています。
以下超訳。

ELF実行時の解釈を"公的見解[*]"に沿うようにするパッチをcommitしました。
これは何かというと、動的リンク時にウィークシンボルの定義を通常の定義と同様に扱うということです。
つまり、weak属性は静的リンク時のみ(それとweak参照でのみ)使われます。

(以下省略)

[*]公的見解 == Solaris、SCOそれにその他のSysVr4由来のUnixはこのやり方で
ELFバイナリを解釈します、ただIrixだけはglibcの以前の挙動と同じですが。

cvswebの変更履歴を追ってみると このcommitの事ですね。

この変更による被害届 その1その2。 とくに前者は仕事だから胃が痛いだろうな、私も似たような経験あるけど。

まぁ Solarisのドキュメントなんかだと「システム以外のアプリでpragma weak使うな」とあるので
自業自得ではありますが、いっそ自前のld.soとlibc、そしてkernelを用意(以下略
まぁふつーdlopen(3)使えってことで *1

しかしDrepper氏の言うように、本当にこの動作が「公式見解」なんでしょうか?
ELF仕様書から一部抜粋してみましょう。

Global and weak symbols differ in two major ways.
  * When the link editor combines several relocatable object files,
    it does not allow multiple definitions of STB_GLOBAL symbols with
    the same name. On the other hand, if a defined global symbol exists,
    the appearance of a weak symbol with the same name will not cause
    an error. The link editor honors the global definition and ignores
    the weak ones. Similarly, if a common symbol exists
    (i.e., a symbol whose st_shndx field holds SHN_COMMON), the appearance
    of a weak symbol with the same name will not cause an error. The link
    editor honors the common definition and ignores the weak ones.
  * When the link editor searches archive libraries, it extracts archive
    members that contain definitions of undefined global symbols.
    The member's definition may be either a global or a weak symbol.
    The link editor does not extract archive members to resolve undefined
    weak symbols. Unresolved weak symbols have a zero value.

以下超訳、ほんとはLinkers & Loadersとかと用語を統一すりゃいいんだけど
いまどこに置いてあるか判りませぬ(CJKV針千本みたいに捨てられてないといいなぁ、しくしく)。

大域およびウィークシンボルの差は大きく二つです。
・リンクエディタは複数の再配置可能なオブジェクトファイルを結合する時
  同名のSTB_GLOBALフラグが立ったシンボルは、これを重複定義として扱い
  許可しません。一方でウィークシンボルと同名の大域シンボルが出現する場合
  これはエラーとはしません。リンクエディタは大域シンボルの定義を尊重し
  ウィークシンボルは無視されます。同じように通常の定義(例えば
  ELF構造体のst_shndxフィールドにSHN_COMMONフラグの立ったシンボル)
  も以下同文。
・リンクエディタがアーカイブライブラリを検索するとき、アーカイブ中より
  未定義の大域シンボルを含むオブジェクトファイルを抽出します。
  抽出されたオブジェクトの定義は大域シンボルかウィークシンボル
  どちらの場合の可能性もあります。リンクエディタは未解決のウィークシンボル
  の為にアーカイブ中のオブジェクトを抽出しようとはしません。
  未解決のウィークシンボルはアドレスを0番地とします。

注意深く読んでいただくと、ウィークシンボルの挙動が定義されてるのは
実のところコンパイル時に静的リンクに使われるld(1)といったlink editorや
lib*.aのようなアーカイブライブラリについてのみだということに
気付くかと思います、そして動的リンクの場合については一切触れられていません。

つまりアプリ実行時に動的リンクの為に使われるld.so(1)のような
runtime link editorやlib*.soのような共有ライブラリについては
仕様を馬鹿馬鹿しいくらいに厳密に解釈するとウィークシンボルの挙動は
「未定義」ということです。

そして先のメールにもある通り、SysV系の多くの実装は
動的リンクの場合はSTB_WEAKフラグは無視するのでDrepper氏はこれが「公式見解」だと。
# まぁ元々ELF自体がSysV由来ですしねぇ。

手元にあるSolaris 8 + SUNWspro WS6U2での挙動。

$ cat >conflict1.c
#include <stdio.h>
#pragma weak foo = _foo
void
_foo(void)
{
	puts("i'm conflict1");
}
^D
$ cc -G -h libconflict1.so.0 -o libconflict1.so.0 conflict1.c
$ ln -sf libconflict1.so.0 libconflict1.so
$ nm libconflict1.so.0 | grep foo
[56]    |      1080|        36|FUNC |GLOB |0    |7      |_foo
[45]    |      1080|        36|FUNC |WEAK |0    |7      |foo

$ cat >conflict2.c
#include <stdio.h>
void
foo(void)
{
	puts("i'm conflict2");
}
^D
$ cc -G -h libconflict2.so.0 -o libconflict2.so.0 conflict2.c
$ ln -sf libconflict2.so.0 libconflict2.so
$ nm libconflict2.so.0 | grep foo
[45]    |      1056|        36|FUNC |GLOB |0    |7      |foo

$ cat >test_conflict.c
extern void foo(void);

int
main(void)
{
	foo();
}
^D
$ cc -L. -lconflict1 -lconflict2 -o test_conflict test_conflict.c
$ nm test_conflict | grep foo
[59]    |    133440|         0|FUNC |GLOB |0    |UNDEF  |foo

$ ./test_conflict
i'm conflict1

libconflict1.soのfoo()が呼ばれていて、確かに動的リンク時には
ウィーク属性は無視されていることがわかります。

*BSD系や昔のLinux/glibcにおいてはSysV系とは異なり
動的リンクの場合も静的リンク時と全く同じ挙動とする扱いだったわけですが
仕様が「未定義」であり、同じSysVでもIrixのような例外ケースもあったのであれば
そのままでも問題ないわけでして。
わざわざ直す必要があったのか正直疑問に感じないでもありません

何か他にも「積極的にウィーク属性は動的リンク時に無視すべき」理由があったとか
情報をお持ちの方は教えていただけると
ひざかたとしちゃんかんげきーちょーっカマ!
キリ。

*1:OpenBSDのようにdlopen(3)が嫌われてたり、NetBSDの__link_set_*相当の
機能が無かったりする環境はまぁBSD Authのよに気合で何とかして頂戴。

異なる-std=*でcompileしたオブジェクトや共有ライブラリは混ぜるなきけん

あとついでですのでもう一点、以前のエントリで触れてなかったのですが
実は今のNetBSDもLinux/glibcもバイナリレベルで互換性を保てないケースが実は存在します。
それは例えば、-std=c89と-std=c99それぞれでcompileされた共有ライブラリをチャンポンで使う場合です。

以下サンプル@Fedora release 8 (Werewolf)

$ cat >foo.c
#include <stdio.h>
void
atoll()
{
	puts("my own atoll!");
}
void
foo()
{
	atoll();
}
^D
$ gcc -std=c89 -shared -Wl,-soname,libfoo.so.0 -o libfoo.so.0 foo.c
$ ln -sf libfoo.so.0 libfoo.so
$ nm libfoo.so.0 | grep atoll
0000045c T atoll

$ cat >bar.c
include <stdio.h>
#include <stdlib.h>

int
bar()
{
	long long int x;

	x = atoll("9999");
	printf("%lld\n", x);
}
$ gcc -std=c99 -shared -Wl,-soname,libbar.so.0 -o libbar.so.0 bar.c
$ ln -sf libbar.so.0 libbar.so
$ nm libbar.so.0 | grep atoll
         U atoll@@GLIBC_2.0

$ cat >test_mixed.c
extern void foo(void);
extern void bar(void);

int
main(void)
{
	foo();
	bar();
}
^D
$ gcc -Wl,-rpath,. -L. -lfoo -lbar -o test_mixed test_mixed.c
my own atoll!
my own atoll!
11400492471025677

わはは。
折角libbar.so.0はatoll@GLIBC_2.0というELF Symbol version付なんだから
ちゃんとlibcのatoll@GLIBC_2.0を呼べないこともない気もするのですが。
当然ながらNetBSDなんかもこういうケースはダメダメです。

COM/COM+/DCOM/ActiveXからはじまってManaged Codeに.Net Frameworkとか
C runtimeはアプリと同じディレクトリとかいいたくなる気持ちは痛いほどよく判るという。
まぁUnixはソースリコンパイル文化のせいで旧態依然としてますやね。
いわゆる.org frameworkってやつか。

今日

お手紙等にはなるべく反応したいと心がけておりますが
時間が無かったりで遅くなること多いです、ご容赦おば。

あとわざわざ メイドが三里塚で成田闘争も日教組冥土への一里塚
誕生日のお見舞い(そーゆーお年頃)のお言葉頂いた方々もありがとうございます。

2008/10/5(Sun)

週末

某駅前、青春パンクがストリートごっこうざいです。
まぁ街頭でJohnny ThundersとかRichard Hellみたいなのがライブやってたら
それはそれでおっかないけどな。

"ゼリー入りこんにゃく"の検索結果 3 件中 1 - 3 件目 (0.26 秒)
独りの夜、いやなんでもないです。

加入してる生保がまたしても事業転売(通算3回目)されそうでわろた。
まぁ葬式代程度にしかアテにしとらんしどうでもいい。

茶道プレイSHADOWPLAYERS観てた、故Tony Wilsonちの猫かわいい。
New Order debut at The Beach Club, Manchester, on 29 July 1980の章で
このネタスレの↓思い出して噴いた。

飯田圭織

「私達の仲間は来れませんでした。
私達は這い回る混乱の唯一の生き残りです。」

(福田明日香脱退直後のライヴでのMC)

原文は"the remants of crawling chaos"だっけか。
しかもおまけの別のDVDの宣伝にThurston Moore(Sonic Youth)と
アイ(ボアダムス)出てきていっそう噴いた。

gimp-2.6はGEGLの試験的な統合とな、うちの14bitなフィルムスキャンデータ扱えるようになったのかにゃ。
8bitじゃどうにもレタッチ耐性厳しいんで、古いカビキズありのフィルムは諦めてたんだが。

鶏雑煮を作ろうとして鶏を買い忘れる不覚。

2008/10/7(Tue)

昨日

最近買ったCD
TWO NUNS AND A PACK MULE / 横8無限大
リア厨の頃このCDとWireのThe Ideal Copyを貸してくれた同級生は
不登校になったきり卒業しちまったなーそういや。

↑聴いてマッタリ(…) しながら、5.0に間に合わせるように作業してるmulti-locale(の一部)コード書き。
とりあえず現状 こんな感じ
ほとんど書き直した。

ちなみに_locale_category_tについては

typedef struct {
        int category;
        const char *(*setlocale)(const char * __restrict,
            _locale_impl_t * __restrict);
} _locale_category_t;

と、setlocale(3)そのままのIFにした、つまりsetlocale(3)は
実装に処理を丸投げちゅーことにした。

一応fallback codeいれてlocale dbがcitrus dbでない時はplain txt dbと仮定して
locale dbの前方互換性は保つようにしたけど、後方互換だけはどうにもならんやな。
古いformatはmagicないし、古いlibcもチェックも無しなので、citrus dbをplain textと
勘違いして即死すると思われ。

いまんとこLC_*をsubdir化してないのだけど(フォーマットをいつでも変更可能なようにおいらはやりたい)
subdir化すれば古いlibcは少なくとも誤作動はせずに、setlocale(3)に失敗するだけにはなる気がする。
#ただsubdir化はコンセンサス取れてないちゅーおいらの認識。

他の残作業はlocale.alias周りを組み込むのと、mklocale(1)でcitrus dbを吐けるようにする作業。
あとcompile optionでlocaleioのコードも有効になるようにすること。
localeio_lc_*がそのコードなんだけど、本体のlocaleio.cがド腐れコードなので
I/F変えん事には再利用すらできねぇ、なわけで現状動いてない。

んで一番めんどくさいのがsrc/share/locale/* のお掃除。
*.UTF-8についてはLC_CTYPEがでかいのでディスク容量を圧迫しないように
塩崎さんがlocale.aliasつーもので対策してるのだけど、他のLC_*では対策のしようがない *1

基本的にsyspkgは言語単位で切り分けてるので、異なる言語を跨ぐaliasとかsymlinkは
やっちゃダメにしなきゃならんのだが、ginsbach氏がグチョグチョにしてもーたのでやる気が出ない。

あとLC_*がフルセット揃ってないlocaleに関しては、消しちまう方向をけんとうちう。
FreeBSDの人数がいて中途半端な状態なら、NetBSDなら(以下略

そいと現状のlibcってLC_ALL環境変数を使って

LC_ALL="ja_JP.eucJP/ja_JP.eucJP/C/C/C/C"

のようにLC_CTYPEとLC_COLLATEだけ違う値にしたいとか出来ないんだけど
これは対応する必要ありやなしや。

ちなみにglibcでも

LC_ALL="LC_CTYPE=ja_JP.eucJP;LC_COLLATE=ja_JP.eucJP;LC_MESSAGES=C ...

は動作しない模様、Solarisってどうだっけか。今度試してみる。

*1:ja_JP.eucJP/LC_*を読み込んでiconvでUTF-8に変換するとかだとCSIの原則に反するしなぁ。

[NetBSD] locale db

いつのまにか某所でlocale db論義やってたのすっかり見落としてた(汗
だからsodaさんsend-prしたのか、どうもすいません。

それにしてもginsbach氏の、FreeBSDのache氏レベルのアーアーキコエナイっぷりに絶望した。
なんだかなぁ、もう最終的な実装イメージが全く違うから話するだけ無駄だ。

もうこれ以上NetBSDに割いてる時間は増やせんしね。
locale.alias処理をどうにかする(今毎回file read発生してるようなので止めたい)のと
mklocale(1)への機能追加が終わったら
yamtさんなりtech-userlevelに投げるなりしてあとはcoreがどっち選ぶか。

ほんとならja_JP.eucJP@UCS4なんかのMODIFIERSネタとか
locale nameのloose matchingも検討したいんだがもう時間切れの様子。

2008/10/8(Wed)

[NetBSD] locale db その2

昨日の続き、localeio側のコードを動くようにした コード
CITRUS=noの場合、localeio側のコードが使われます。
って、rune_lc_template.hをincludeしたお陰でキャッシュが有効になったりして
高機能になっとりやすが。

あとlocale.aliasの処理を追加(時間がないので毎回ファイル読むまま)したので
Pig localeなんかも動くようになったはず。
つかCITRUS=noの場合、localeに依存するstrcasecmp(3)呼ばれたり
結構マヅイことになってた。

おまけでmulti-localeの機能も一部デモ用に入れた。
つかここまで大きく書き直すした理由としてmulti-localeがないと
ケチつけたいヤシの餌にしかならん。

ちゅうことで残作業はmklocale(1)にgenlocale相当の処理を乗せる。
まぁ今のplain text dbでもsim用意してあるので動くんだけどさ。

あ厳密にバイナリ互換を保つためにsetrunelocale.cのsimを実装する作業もあるか。
こんなのは正直けちゃぶったっていいけど。

"けちゃぶる"の検索結果 2 件中 1 - 2 件目 (0.40 秒)
今作った言葉だしな。

localeioのコードではopen(2)したのがファイルかディレクトリかチェックしてないので
もしsubdir化するとcore吐きまくる事になるようだが、もうね(以下略

ほんとうはさ、ファイル読み込みのルーチンはloadable moduleにすりゃいいんだよ。

/usr/share/locale/ja_JP.eucJP/LC_CTYPE
/usr/lib/locale/ja_JP.eucJP/libLC_CTYPE.so

とかやっといてdlopen(3)すると。
これならLC_CTYPEのファイル構造変えたらlibLC_CTYPE.soも変えればいいだけ。
まぁもうこんなんやってる時間無いけど。

もうちょっとがむばって、coreに投げたら6.0ターゲッにのんびりやれるといいなぁ。
あnviのpatchがまだあるのか。

しかし性能試験までやっとる時間ないのが困りもの。
あんまり芳しくないようならちまちまkey/valueで引くのでなく
regionでがっつり取ってきたり、strdup(3)せずにmmap(2)しっぱなしとかも
検討しないとならんのだが。

しかしおいらは何時pcc(1)いぢりに戻れるんだ。

つかやっぱリリースなんてOpenBSDのようなcurrentのsnapshotでいいよもう(ぉ

2008/10/9(Thu)

[NetBSD] multi-locale (i am the resurrection) その?

glibc2の挙動チェック。

$ /emul/linux/bin/bash
bash-3.00$ cat >test.c
#define _GNU_SOURCE
#include <ctype.h>
#include <locale.h>

int
main(void)
{
	int x = isalpha_l((int)'A', LC_GLOBAL_LOCALE);
}
^D
bash-3.00$ make test
cc    -c -o test.o test.c
bash-3.00$ ./test
Segmentation fault (core dumped)

あひゃひゃ。

LC_GLOBAL_LOCALEは静的記憶域期間でも有効なので *1
glibc2の実装では

# define LC_GLOBAL_LOCALE       ((__locale_t) -1L)

となってるにも関わらず

bash-3.00$ cat >test.c
#define _GNU_SOURCE
#include <ctype.h>
#include <locale.h>

int
main(void)
{
	int x = isalpha_l((int)'A', NULL);
}
^D
cc    -c -o test.o test.c
test.c: In function 'main':
test.c:8: warning: dereferencing 'void *' pointer
test.c:8: error: request for member '__ctype_b' in something not a structure or union
make: *** [test.o] Error 1

ちゅうエラーを出すことから判るとおり、isalpha_l()をマクロとして
実装してんだな、こりゃ。
なもんで、-1にアクセスして落ちると(笑)

うーんMacOS Xはどうしてんだろ。
man(1)はisalpha(3)のおまけとしてしか書いてないんでよーわからん。

個人的にはlocale_tはopaqueにしたいのでこんな実装は勘弁して欲しいのだけど
性能次第ではやらんとならんな、ゲロゲロ。

*1:なので私の以前の実装のように_LC_GLOBAL_LOCALEを
関数呼出のmacroとしてはしてはならないわけだ。

今日

なんもやるきがしないわー、えい天気良くなれ!

SONY α200はUSBでマスストレージとして見えるのだけど
給電はUSBの方は使わないので本体のバッテラが必要なのがちょいダサイ。
ちなみにACアダプタもないかんね、縦グリにはあるんだっけ?
まぁCFアダプタ使うからいいのだけど。
それとやっぱり本体の液晶じゃぁ露出も色も判断できんわ。
ヲ、ナイス写真と思って後からCRTに出力してみると露出ボロボロとか
正直無いほうがまし、脂で汚れるのも気になるし。

2008/10/10(Fri)

[NetBSD] multi-locale (i am the resurrection) その??

これまでMacOS Xのまぬある読みながら実装してたんだが
今回ちゃんと真面目にLSB 3.2.0の仕様を読んだらかなり相違があって黒い血噴いた。

例えば

locale_t newlocale(int mask, const char *name, locale_t base);

について、前者はERRORセクションないんだけども、後者ではばっちり定義してやがる。
あとbaseにNULLやLC_GLOBAL_LOCALEを指定した場合の動作を前者は定義してるけど
後者は未定義なようで、現物(=glibc2)を確認するとSegmentation Fault起こすな。
あとおいら勘違いしてたのだが、baseがNULLでないときはbaseの値を変更して
返すという仕様だと思ってて

	locale_t x, y;
	x = newlocale(LC_ALL_MASK, "ja_JP.eucJP", NULL);
	y = newlocale(LC_ALL_MASK, "ja_JP.UTF-8", x);
	assert(x == y);

が成立すると思ってたのだが(でないと一度作成したlocale_tは二度と変更できねぇ)
どうやらあくまで"new"なので、常に新規locale_t objectを作成して返すようだ。
まったくどこまで頭悪いんだこのウンコ仕様は...

そいとMacOS Xの通りにやろうとすると

という事なので、Thread Local Storage実装するかあるいはerrnoと同じく
pthread_tにcurrent localeを保持するfieldを追加するかせんとならん。
どっちみちlibpthreadとかld.elf_soとかおおごとになるので間に合わないんだが
glibc2と同じ動作にすると将来困りそうだな。

duplocale(3)、freelocale(3)も以下同文、後者はプロトタイプまで違う。
もういいや、*BSD仲間ってことでMacOS X風の実装にすんべ。

つーことでuselocale(3)とper-thread current locale(スタブだけ)を
突っ込んでみたが、これまでglobal localeの初期化は
_lc_global_locale()ちゅー関数内で

static _locale_impl_t _global_locale;
static int _global_locale_initiazlied = 0;
_locale_impl_t*
_lc_global_locale()
{
	if (_global_locale_initialized == 0) {
		l = _find_category(LC_ALL);
		(*l->setlocale)(_C_LOCALE, &_global_locale);
		_global_locale_initialized = 1;
	}
	return &_global_locale;
}


ちゅうようにsetlocale(LC_ALL, "C")相当でやってたんだが
これアウトになるので、静的に初期化かけんとならんのだな。
そうすると__link_set_*使って実装を隠蔽するのが難しくなるよな。
うーむ困った、もう__link_set_*使うの止めちまうかな。
そもそもOpenBSDには同等品ないし(まぁ突っ込むのは簡単だが)。

2008/10/11(Sat)

[NetBSD] multi-locale (i am the resurrection) その???

最新、いろいろ日和って_RuneLocale(runetype.h)及び
_{Monetary,Numeric,Time,Messages}Locale(localedef.h)を
libcから完全に分離して置換可能にするのはいったん中止(笑)
あぁこんなはずではなかったのに。

i'm doing the best that i can
i'm ashamed of the things i've been put through
i'm ashamed of the person i am

とか歌ってしまうぜ。

まぁ_locale_tはconstructor/destructorがあるし、ABIに影響でないしね。
他にもやりたいことはあったけど時間が無いや、6.0(7.0?笑)への課題ちゅうことで。
一応ctype/wctype/multibyte_c90/multibyte_amd1の*_lも入れてあるけど
5.0に突っ込み気はありません。

___runetype_mb.cとかsetrunelocale.cなんかで、もう使わない関数があるんだけど
厳密にABIを保持しようとするとsim残しておく必要あるんだけど、要らないよね。

つーわけでmklocale(1)にcitrus dbの機能のっけたら某所流して
nvi 32bit cleanのpatchを修正する作業に戻る。

今日

十月桜、桜は上手に撮るの難しい。

我在TOWER RECORDS。
やたらこの媚びを売ってくる音はオェイシスの新曲だったのか。

90/ 808Stateが再発してた、Cobra Boraとかナツカシス。
これ以降のテクノって細分化され過ぎておっちゃんよく判らん。

んで結局買ったCD チョメチョメの歌 / The Big Black
先日に続いて懐かしのSteve Albini Classics。
買う時、クレカの読取が不調なようで何度も商品のバーコード読み直しになったんだが
このCDは裏ジャケが表以上にサイテーな これのヒトコマなので
女性店員の目が若干怒色を帯びてた気がする、ごめん。

前者はTB-303、後者はTR-606ちゅー発売当時は鳴かず飛ばずの
電子楽器をビンテージとか有難がって大金積んで買う風潮を生んでしまった
罪作りなCDのうちの一枚だな、才能ある奴はバケツ叩いてもカコイイ。

まぁTR-909は神いわゆるゴッドですが。

遂に the Replacementsが再発しかもリマスタ! ktkr!!
うわーこれでPaul Westerburg来日しねーかなー100%無理だろうが。
そもそも日本盤(以下略

十三夜、やっぱり旧暦8/15より同9/13の月の方が好きだな。
安物の70-210mm/F3.5-4.5で撮ったのをトリミングでこのサイズに。

2008/10/13(Mon)

[NetBSD] multi-locale (i am the resurrection) その????

mklocale(1)も修正した 最新版、 localeioの__convertgrouping()が
strtol(3)に依存してマジで血管切れる5秒前だったが
FreeBSDからfix_grouping.cをパチってきて回避

...できたたかなー思ったらisdigit(3)呼んでて泣いた、おっおっ。

ちゅうかなぜ彼らはsetlocale(3)の内部処理で、localeに依存する関数を
呼んじゃ駄目とい事に気付かんかな、プログラミングの基礎だろJK。

まぁ本当はsnprintf(3)なんかも駄目なんだが、そこまで徹底するには
完全にmulti-localeの実装が終わらないと無理ぽ。

じゃぁなぜここの部分のstrtol(3)やisdigit(3)だけは放置したらまずいかというと
mklocale(1)はcross-toolchainなので、strtol(3)やisdigit(3)は
hostのlibcのものが使われてしまうちゅーのが理由。

joerg氏が先日strtolファミリーをtemplate header化してくれてたお陰で
助かった、tools/mklocale/safe_strtoul.cね。

あとNetBSD toolchainってよく知らんのだけど、fix_grouping.cはCHAR_MAX使うんだが
これhost環境のCHAR_MAXになっちまう気がする、これなんかnbcompat.h的な
ものの中でtarget環境のCHAR_MAXを使うようになっってるんだっけ?
常識的に考えるとそんなん無理、な気がするんだけど。

そいや以前FreeBSDで_RuneLocaleがpublicな為toolchainのbuildがこけるんで
_NBRuneLocaleにrenameかけたりしてた記憶がある、やっぱり駄目か。

つーわけでそこもTODO追加。

まぁでももうcoreに投げても良い頃合いだろかね。
なんかここがダセェー、ゲロの臭いが(以下略)な部分があったらご指摘ください。
もうすでに_RuneLocale(runetype.h)及び_{Monetary,Numeric,Time,Messages}Locale
(localedef.h)を分離する時間が無かったので、個人的には好かんコードなんだけど。

がーそういやCHAR_MAXはMDだった、ということはlibcはdbを読んだ後に
3;3;-1 -> \003\003\117\0に変換かけねばならなんのか、うわー無駄だ。

2008/10/14(Tue)

連休

鳥雑煮を作り過ぎて2度と見たくない状態に遷移。

Minolta XDを一台買い増し、整備済品つーことだったのに
この機種のとろける巻き上げ感が損なわれてて大変残念な結果に。
まぁ基本動作は問題なかったのでいいや。

それ以外はおおむね体調不良でダウン、Mehr Licht!

ライトスタッフ、困難なテストのわりに給料が安いと、わかります。

原作本読んで、当時のエドワーズの死亡事故の多さ&パイロットの週給の低さに驚いた記憶がある。

カウボーイ映画の手法で描くイエーガー(ガンマン決闘=記録挑戦)の話を挿入しつつ
ロードムービー映画の手法でマーキュリー7(行き先=砂漠から宇宙、珍道中=奇妙な訓練+検査)を
メインに話が進むので(イエーガーは馬に、ゴードはオープンカーに乗って登場する対比など)
後者の手法を生理的に受け付けない人には「長い」「退屈」なんでしょう。
ロードムービーいけるくちならBell X-1がどーだの知識は無くても楽しめる映画だと思います。

ただアランの打ち上げ時の"i'm a wetback now"の訳とか、字幕はいまいちだったかも。
wetbackにはメキシコ国境を越える不法移民の意味があるのが全く伝わらないという、字幕じゃ難しいか。

2008/10/15(Wed)

[NetBSD][pkgsrc] firefox2 + acroread7

あれ? うちのnative firefox2 + nspluginwrapperだとacroread7のプラグイン動いてますけど。

__sFってNetBSDのlibcのsymbolなので、libpixman-1.so.0はおそらくNetBSD native
んでpkgsrc/emulators/suse100_gtk2はlibpixmanをlinkしないので
想像するにacroread7がnativeのgtk+2(こっちはlinkしてる)を間違ってloadしてるような。
ld.so.confとか環境変数LD_*あたりの問題?

余談ですが、acroread8はLinux emulationがkernel2.4のバージョンを返すので
glibc2のThread Local Storageが有効にならないとかで動かないみたいですね。

2008/10/16(Thu)

[NetBSD][pkgsrc] fontconfig

fontconfigがja_JP localeの場合、デフォルト(ちゅうかfallback)に
12x13ja.bdfを使うのでfirefoxのUI表示が崩れる 問題。
これは NetBSDの設定が悪いちゅーよりも、等幅なbdf(XLFDでいうとこの-c-)って
文字集合がiso10646-*(=Unicode)の場合はレンダラがもっと頑張らないと駄目だよね
って話ですかね。

X{mb,wc,utf8}TextEscapement(3)とかの返す文字幅のピクセル数ってXLFD、つまり

Foundry-Family-WeightName-Slant-SetwidthName-AddStyleName-PixelSize-PointSize-ResolutionX-ResolutionY-Spacing-AverageWidth-CharSetRegistry-CharSetEncoding

-misc-fixed-medium-r-normal-ja-13-120-75-75-c-120-ISO10646-1

でいうとこのpixel sizeを計算してまして、wcwidth(3)のようないわゆる
「半角/全角」ちゅうものは一切考慮してないのですよ(実体はXTextWidth(3)だったかな)。

これまでeucJPなんかだとXFontStruct(3)なんかを使って

*.fontList: \
	-misc-fixed-medium-r-normal-c-14-*-jisx0208.1983-0, \
	-misc-fixed-medium-r-normal-c-14-*-jisx0201.1976-0

ちゅー感じで半角(7x14)/全角(14x14)フォントを組み合わせて使ってたので
X{mb,wc,utf8}TextEscapement(3)側で全角/半角が考慮されてなくても
(一見)正しい幅で表示できてたわけです。

ところが12x13ja.bdfの場合、グリフで全角/半角をデザインしわけたとしても
pixel sizeはあくまで「12x13 pixelの等幅」なので、隙間が空いてしまうんんですよね 。
それを嫌ったのかMarkus Kuhn氏は0x21-0x7EのグリフにJISX0208と同じいわゆる全角英数を使ったんじゃないかなと。
# まぁそもそもUnicodeでは文字幅は定義しないという建前だし。

つーことでUnicode的には文字幅の問題はレンダリングエンジンにおっかぶせたにも関わらず
誰もX{mb,wc,utf8}TextEscapement(3)を修正する、か…漢はいなかったんじゃないかと *1
# 当時はKeith Packard氏がXftとか出してきてXLFDの方は捨てるゆうとったし。

んな訳ではISO10646でbdfの等幅フォント使うのは鬼門だちゅうことで
mona fontに含まれているプロポーショナルなbdf(XLFDでいうとこの-p-)を使って回避した訳です。

なもんで-c-なフォントのつもりが実際は-p-が使われてるので、テキストボックス内の文字が消えたりする
不具合なんかがちょろちょろありますが、アホ臭くて調べる気にもならない。

それと記憶は怪しいのですが、li18nux/openi18nでやってたXlib-I18N実装ではこの問題を
改善してたと思うんだけど、なぜかxfree86にもxorgにもマージされずじまいだったような。

ちなみにPangoのX bindingでFontListだかFontSetの指定ができるはずなのですが
最近のgtk2では既にlibpangoxを無効にされてしまってた記憶があります。
それにfirefoxの方も3になってcairo化されてるので、もう何がなにやら。

pangoとかcairoの話って Fonts & Encodingsで解説されてるのかね?目次だと駄目そうだけど。

結論としては素直にTrueType font入れるのが一番なのですが、おいらold schoolなのでbdfでおk。
ちゅうかなんでもアンチエイリアスきもいです><

アンチアンチアンチアンチアンチアンチエイリアス

STSFがデスクトップを制する平行世界では今頃どうなってるのだろうか。

*1:つか-c-でもプロポーショナルのよにaverage width=0とか駄目なのかな。

昨日

曇で満月見えず、これがクラウドってやつか。

昔のエロは黒塗りやモザイクでクラウドだったものだ。

Java屋から足抜け?したおかげでこの手のどうでもいい単語の説明を求められないので楽になった。
ちなみに今の現場は 釣り or ゴルフ or FX に精通した奴が一番技術レベルが高いということになってる。
救済措置としてガンダムネタ(ファーストのみ)も許容されているとこがITだね!

ちなみに俺はどれも嗜まないので一番技術レベルが低いです、はい。
釣り面白そうなんだがここの本気と書いてマジの海釣り野郎ども相手は、すぐに船酔いする俺は無理。

一部の店舗で、ネコ撮り神SONY α300がボディ6万、下取7千、キャッシュバック1万
それにポイント還元で、実質3万6千円程度で買えてたらしい、運動会商戦まで待てばヨカタ。
キャッシュバックは昨日で終わりだったようでトキスデに遅し。

α200はちゃんとDC-INあった、なんかもう頭腐ってるな俺。

オートホワイトバランスがなんでも白くしようとするのが困る。
蛍光灯の色はちゃんと薄汚い緑に出ないと雰囲気出ないだろJK。

2008/10/17(Fri)

[NetBSD] multi-locale

塩崎さんところ、レビューありがとうございます。

rune_*は確かに好ましくないですかね、元はruneだったコードちゅう意味くらいで使ってたんですが
名前空間的にあんまり宜しくないですね。

nb_*にするか(発想がプア)、またこれでOpenBSDで(以下略

ご指摘いただいた部分直して来週頭にゃ某所投げれるといいなぁ。
なんかいつのまにかrevivesaがHEADにmergeされてたようで、5.0枝はロスタイム突入らしい。

/usr/src/share/*のお掃除とかどうすっかな、特にLC_MESSAGESはinstallするだけで
multibyte aware regex(3)が無いからja_JP localeなんかじゃもれなく誤作動するという
ご指摘を以前yamtさんから頂いてるのだが。

他にもsodaさんからメール頂いてるのだけど
ちょっとbsd-locale-jaあたりで要相談かな、ちょっとメール書くか。

64bit time_tの為のlibc major crunkは某所で6.0にリスケされてたと思いますので、まだ余裕あるかと。
_ctype_ tableの32bit化と、あとwchar_tをint -> unsigned intにしないとですね。
GB18030の4byteコードで、32bit目使っちゃってるのでwchar_t as intだとnegative値になってしまいますので。
この話ね。

あと以前_locale_tを実装するとき、sodaさんよりtypedef void * _locale_tだと

「void *」は(利用者にとって)型チェックが効かないケースが多いのでできれば避けたい

というご指摘を頂いたのですが、現状iconv_tとかwctype_t/wctrans_tも同じ問題あるんですよね。
これもあわせて直した方がいいかも(wctype_t/wctrans_tは仕様でスカラ値であることが求められてるけど)。

えっとGNU libiconvとglibc2はtypedef void * iconv_tか。
Solarisの場合、iconv_tの内部実装struct icvはばっちしiconv.hでpublicになってて
typedef icv *iconv_tとなっているわ、これは漢だ。
opaqueにするなんてなんて弱虫(ぉ

そもそもNetBSDもlocaledef.hなぞpublicにすべきじゃないんだけど、これSysV由来だっけか。

2008/10/18(Sat)

[NetBSD][pkgsrc] fontconfig その2

sodaさんからメールいただきました、もったいないので転載:)

LINK /diary/?20081016#16-1 /diary/?20081016#16-1
> 等幅なbdf(XLFDでいうとこの-c-)って文字集合がiso10646-*(=Unicode)の場合は

いやー、-c- で -ISO10646-1 ってのは、存在自体が間違いってのが
正解でしょう。

-p- で -ISO10646-1 なら、携帯電話とか、PDA みたいなプアーな環境で
のみ使うってのなら、ぎりぎりセーフな可能性もありますが。

複数のフォントが使える状況で、-ISO10646-1 みたいなでっかい文字集合の
フォントを使うなんてありえないです。
てゆうか、-jisx0208.1983-0 でさえ、既に十分大き過ぎる (仮名とかだけ
別のフォントを使いたい) ってのに…

こんなこと、1990年代前半にはみんな分かっていて、だから FontSet だった
のに… ぶつぶつ…
--
soda@原理主義者

レンダリング側としてはXFontStruct(3)がある時点で
立派に責任を果たしてるというわけですやね、なるほど。

xterm(uxterm)なんかだと-iso10646-*フォントを要求する上に
文字幅問題の解決には+/-cjk_widthスイッチをつけろという
ちょっと原理主義というか正統派w的には信じられない対応というわけです。

記憶が怪しいですがFreeBSD ports方面にあったfontconfig CJK patch
なるものもこのUnicode CJK widthを実装するというものだったっけか。

じゃなぜFontSetを使わずiso10646なのかという点について
私の考えとして↓な返事を書いたのですが

UCS4<->JISXの変換テーブルをlibX11が持たないとならないですが
xttはちゃんと持ってたし、今のXFree86/xorgでも
${X11_BASE}/lib/X11/fonts/encodings/* があるわけですから
FontList/FontSetを使うことに何の問題もないわけですからねぇ。

# どうしてもUnicodeが主役じゃないと気に入らないのだろうか。

わははHaterだ!Hateがきた!(笑)↑こっちの文責は俺(=tnozaki)ですよ。

これに対するsodaさんのお返事は

いや、この件は Unicode 好き嫌いとは独立した話です。

Unicodeが主役の場合、変換テーブルは持たない場合でも、
やっぱり BMP を1つのフォントで持ってちゃ駄目で、分割しないと
いかんし、FontSet は必要なんですよ。彼らはそこが分かってないんですね。

とのお考え。

やっぱりfontconfigの立場が微妙なんだろうなぁ。

fonts.dir

なにそれ

だるいし

xtt

ttcapとか書くわけないじゃん

てかツールで検索して見つかった

物理フォント

自動で管理名振ってろよ

勝手に

みたいな

というスタートなのでしょう、だからfc-cacheで自動化できない
好みのbdfを組み合わせてFontSetを作るようなものは捨てたと。

結局fontconfigを直で使わないでlibpangox使えってことなのかな。
だとするとlibpangoxサポート捨てたgtk2がアレなのでしょう。

結論としては

> 多分gtk1使うのが一番いいのかと。

はい。firefox-gtk1 使ってます。^^;

というところで一件落着(ぉ

今日

茶店でコード書こうとThinkPad s30で久々にモバイル(笑)したら
液晶が点灯しなくてゲームオーバー、ぐええ。

今バラしたら以前インバータのフレキを差し込むコネクタ部が
完全に剥がれてた、以前半分ほど剥がれたのを無理矢理修理したんだが
更にに劣化が進行していた模様。
ROHS導入で電子製品が壊れまくりゴミ増加だな、環境(笑)

ThinkPad 240の方も先日WAPBLがらみでディスクをトバしたので復旧すんのカッタルス。
しょうがないのでVAIO C1XGを発掘してきたが起動しないわ。

半年近く放置状態のX61から冷たい視線を感じるが、セットアップすんのめんどくさ(ぉ

時々お手紙頂くのでコメント欄くらいつけようと思ったが
TDSの標準機能じゃ古過ぎるので、コメントspam対策追加せんとならんなぁ。
めんどくさいので(NetBSD時間で)そのうち。

whitespace風CAPTCHAというものを考えたのだが
一般利用者には投稿がほぼ不可能になるにもかかわらず
SPAM業者には総当り攻撃が簡単になる、ちゅーことに気づくまで
およそ5分ほど要した、俺はもうマからは足を洗うべき。

2008/10/20(Mon)

[NetBSD] いろいろ

pkg/39765へなへな。

今回のPRはサンプルだからいいけど、これ実際にやっちまったアプリってどれくらいあるんだろう。

tech-userlevel、getdelim(3)とgetline(3)はTR24731-2にもあるのだが書いてないわ、そいや。
まぁfgetln(3)元にちょちょいう書けるので放置。

Q 急に
T ThinkPad s30 が
K 壊れたので
結局のとこ某作業を進める作戦失敗(ぉ

コネクタの足はピッチが0.2mmもないので
完全に剥がれる前ならまだしも、再半田はおいらそっち方面はわりと不器用なので無理げ。

まんどくさいからX61プリインストのVista上にVMware入れちまうか。
どうせおいらkernel developerじゃないし。

週末

バスの中ででっかく「HATE」と書かれた帽子を被った60過ぎくらいのおっちゃんを目撃。
孫のお古を意味わからずに被ってるのかそれとも「PPMD」に呼応して
団塊世代がライトマイファイアーしちゃったのか、判断つきかねる。

HATEな diaryで帽子を脱ぐとモヒカ(以下略

archivers/ppmdとは関係ありません。

つーわけでやること無くなった(事実誤認)ので、某所のジャンクワゴンから
部品鳥用にMinolta NEW X-700とHi-Matic E不動品をゲトしてきた。

…ちょっと掃除しただけで動いてしまった、これじゃドナーにできんぞ。

もうbootp鯖立ててインスコすんのめんどくさいので
結局USB接続のPortable DVD drive買ってきた、イタタ。

最近読んだ本。

2008/10/21(Tue)

[NetBSD] locale db その3とか?

Reduce locale shared object size
Solarisの場合はインストーラーで必要なものだけ選ぶのがほとんどだと思われるので
ここまでする必要がどれほどあるかは知らないけども、やっぱりUTF-8(以下略

NetBSDの場合はbuild.sh install=/で全部入っちゃうから(syspkgはもう駄目そうだし)困るのよな。
しかも組込のような容量に制限きつい目的で使われること多いわけだし。

それゆえに現状LC_CTYPEについてだけ、locale.aliasちゅう仕組みで
UTF-8ロケールは全てen_US.UTF-8のaliasになってたりする(かなりevil)。

でもLC_{MONETARY,NUMERIC,TIME,MESSAGES}の場合は同じUTF-8でも言語地域が違うとaliasにはできない。
じゃぁja_JP.eucJP -> iconv(3) -> ja_JP.UTF-8?それもなぁ、ということを 以前書いたけども
5.0にこれ必要になるので、早急にアイデアを纏めてbsd-locale-jaあたりに投げる事。

ちなみにsodaさんはiconvでいいんじゃ?と。

昨日

半年経った。
夜は暗く、土は冷たくなったにゃ。

>>72パリ、テキサスならぬ 原宿、戸塚ってやつですな。
前者にはのぞき部屋(keyhole club)があるけど、後者にはのざ(略)がある、ふしぎ!

そいや パリ、川崎なくなっちゃったな。
i fell right into the arms of venus de milo.

なぜかいい年こいて ランボー詩集なぞ読んでいる。

今度は戦争だ


みたいな


つーネタ抜きに、ランボーはランボーがモデルなんだっけか。

ミノAF28-85mm/F3.5-4.5初期型がジャンクワゴンで1000円だったので買ってきた。
同レンズのNEWと比べるとメリットはマクロ機能、デメはずっしり重量かな。

花屋。

2008/10/22(Wed)

昨日

さてどの記事書くかね。

は危険だからやめておこう。

元ネタ、なんか最近の新書(笑)の手法ですな。

胃薬切れたので昨日はさっさと牛乳飲んで寝た。

[NetBSD]

five minutes work, ちょっとだけmulti-locale 直した

grouping + MD CHAR_MAX対策はまだやってない。
あと試験的にlocale.alias + iconvも実装してみるかな。

それとsubdir化どうすんべか。
localeioはstat(2)してS_ISREGかのチェックをしてないピーな実装なので
S_ISDIRだろうがread(2)しちゃうぜアッーなのでLC_*をsubdir化すると古いlibcだと
core dumpしまくりんぐなのだよな。

最低でもLC_CTYPEと同様にmagicの有無を確認するとか
locale data構造体のサイズ分だけは最低でもread(2)に成功するか確認しててくれりゃ
こういう問題は起きないんだが(そうすりゃcore dumpせずsetlocaleに失敗するだけで済む)
なぜかfstat(2)のst_sizeが1以上かのチェックしかしとらんという。
百万回fstat(2)のマニュアルを読みやがれといいたいのだが、トキスでにオソし。

というわけでsubdir化するとバイナリ互換で問題あるのだけども
こないだのlibpthreadのように、currentだからバグって事でメンゴで済ますか。
libcの再コンパイルだけで、pkgsrcには影響でないし。

gettext(3)問題があるのでLC_MESSAGESだきゃsubdirにしないとまずいのだよな。

そいとginsbach氏、gencat(1)のマニュアル書き直したりしてるけど
もしかしてlocale dbのversioningを問題にされたからって
LC_*をcatgets(3)で実装しようとか斜め上な事考えてないかちょっち心配、杞憂かね。
catgets(3)はgettext(3)のよにPRIマクロ対策がされていないからMDとか理解してるか不安。

2008/10/23(Thu)

昨日

multi-localeは、ちょっぴりコード整理しただけで進展なし。

2008/10/24(Fri)

昨日

OLYMPUS-PEN EEDを500円で拾ってきて修理している。
同じF.Zuiko 32mm/F1.7 *1を積んでる同D3は、中古相場は1〜2万円ぐらいするんだけど
こっちはフルマニュアルじゃないAE機だから人気薄なのよな、でもいいカメラよこれ。

シャッター不動だったけど中の棒が曲がってたのを直して復活。
露出計が動いてないので断線してるっぽい、テスターどこ仕舞ったっけ。

マイクロフォーザーズに期待すること
マウントアダプタで古いレンズもウハウハっても、撮影素子小さいから
銀塩135用のレンズは2倍の画角(50mmの標準が100mmの中望遠)になってしまうのが微妙だわな。

良いとこ探すとなると

あたりか、でもこれ結局クロップ or デジタルズームと同義だよな。

やっぱり大きさを生かして、サブとして使うくらいしか思い浮かばない。

*1:スペック一緒でも設計は違うらしいけど

2008/10/27(Mon)

週末〜今日

体調不良、ナメクジに塩で一回休み。

QTK(急にThinkPad s30壊れたので)、tnozaki AT NetBSD DOT org 宛てのメールをfetchしてない間に
某所でいろいろメールが飛び交うというミッフィーの法則、ごめんなさい明日くらいに返事書きます…

ちゅうわけで開発環境復活作戦、ただいまdumpちう。

原子力発電所の炉心部分が、実は1つのコードで進入出来ていた、という話
こんにちは!こんにちは!

原材料の高騰で、いつのまにかカミソリの刃が一本減ってるな。
うそで(略

*_sって直接使うのではなく、/GSオプションで事前定義マクロ有効にして使うもんじゃなかったっけ?
手元にVC++6.0しかないのでよう知らんけど、そもそも明示的に*_sを呼ぶと移植性(以下略

まぁISO/IEC TR24731-1がacceptされればC1XではOKなんだろけど、こっちは雲行き怪しかった記憶。
しかも 微妙に差異がある

gcc(-fstack-protector) + libsspの場合、*_chkというサフィックスの関数に置換されるので*_sは余計なもの(-1) *1
たうぜん、手動で*_chkよんだりは推奨されない。

NetBSDローカルでは efun(3)というものがあるけど、これはエラーチェックの共通化が目的なので
手でセコセコ置き換える必要がある、あとたうぜん移植性は無い(libnbcompatにあるかも)。

*1:以前tech-userlevelにfmemopen(3)絡みで NetBSD向けTR24731実装
ネタを振ったら見事にスレストッパーとなった記憶。

2008/10/28(Tue)

昨日〜今日

ThinkPad s30がdump中に刺さりまくりんぐで開発環境復活失敗。
仕方無しに久しぶりにOutlook Expressなぞ起動してメールチェック。

体調更に悪化、会議の予定あったので無理矢理出社する責苦。

[C言語] strcpy_s

ありがとうごじゃいます、cl.exeのオプションに/GSスイッチつけると
事前定義マクロ_CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMESがONになって
strcpyはstrcpy_sに置き換えられ、ワーニング(当社指定用語)出ないようになると思ってますた。
これがソース囲い込みってやつ(違

まぁマクロで置換だと動的に確保したメモリには無力なわけで、手動で置換しないと意味ないか。
OpenBSDなんかだと(NetBSDも) strlcpy/strlcat推奨、のtheo氏なわけで、こいつらも移植性ないしね。
ちゅうことで移植性考えるのなら

#if !defined(HAVE_STRLCPY)
#if defined(HAVE_STRCPY_S)
#define strlcpy(dst, src, len) strcpy_s((dst), (len), (src))
#else
#error "no strlcpy function"
#endif
#endif

くらいやらんと駄目なわけですな、autoconfマンセー(大嘘

0x5C

PHP、namespaceのセパレーターに\(←なぜか円マークに見える)を採用。
またCitrusの iconv -f eucJP -t Shift_JISで0x5cが変換できないことに対する挑戦が(事実誤認

ここんとこLC_MONETARYの実装をしてて笑ったのが、FreeBSDの定義ファイルが
ja_JP.eucJPの場合、currency_symbolに0x5C(=バックスラッシュ)を割り当ててる件。
まぁ俺でもそうするだろうけど、いろいろ複雑な気分だ。

ちなみにLinuxの場合

LANG=ja_JP.eucJP locale -k currency_symbol
currency_symbol="¥"

という正しいけどさぁ…ちょっとこれは…な表示をしてくれる模様。

LC_NUMERICのdecimal_pointとthousand_sepは ISO/IEC TR14652
明示的にmultibyteの指定は禁止されてる(正確には未定義動作)のだけども
currency_symbolなどは全然OKなのだな。

そいや先日書いた Portable Charcter Setの件
真面目に仕様書読むと、PCSにはバックスラッシュを文字集合に含まれていることとあるので
NetBSDのようにPCS=ISO646-BASICとしてja_JP.SJISを許可するのはPOSIX不整合でんな、困った。
これ多分Citrusが多くを参考にしてるSolaris由来なんだが、あっちのja_JP.PCKの0x5Cってどうなってるんだっけ。

んでPCSには0x1B(=ESC)は含まれていないので、ISO 2022なlocaleを実装するのは何ら問題がにゃい。
まぁPCSをUS-ASCIIとして実装してる場合は、ISO 2022とUS-ASCIIは互換性がないので無理ですが。

んでMirBSDのよにPCSをUTF-2(CESにUTF-8、CCSにUCS2)とかすると、んーまぁどうでもいい、知らん。

結論としては、日本の通貨記号をバックスラッシュにすれば丸く収まる、¥は中国様に進呈すべ(やめなさぃ

2008/10/29(Wed)

昨日〜今日

The Missing Boyby Durutti Column

一年は本当にあっという間。

やっと固まること無しににlevel 0 dumpを採集、あとはThinkPad X61にVMware突っ込むかいの。

とりま英文メール書いてる、書き終わったら投げる。

ここんとこ体調悪いのは配管が腐食して漏れてて貧血起こしてる様子、イカスミ状の(以下略
穿孔ちゅうわけでもないのとカメラ呑むのはもう嫌なのでしばらく様子見る。

C99の可変長配列は__buildin_alloca()と同義だから注意、という話を以前軽く書いたけど
この記事(from undeadly)にしっかり書いてあるの。

カップ麺、うちの選挙区がお騒がせしております。
民主が小泉シスターズにインスパイヤされて投入した候補だししょせんこの程度。

つか外交防衛委員会だから自衛隊の調達価格が400円だったりして。

どうしても貧困層煽りたいんだろうな。
envy is useless emotion, つか7つの大罪だったっけ>嫉妬。

2008/10/30(Thu)

[C言語] alloca(3)

tamoさんとこ、あー確かにalloca(3)の戻り値問題までは触れられてないですね>元記事。

そもそも FreeBSDOpenBSDのmanだと alloca(3)が失敗した場合、NULLを返すとは書いてないのよね。
NetBSDのやつには書いてありますが

If the allocation failed, a NULL pointer is returned.

んでBUGSにひょろっと

The allocation made may exceed the bounds of the stack, or even go further
into other objects in memory, and alloca() cannot determine such an error.

とか書いてる通り、stack overflowが発生した場合戻り値はNULLになりません。

glibc2のmanが一番まともかな。

If the allocation causes stack overflow, program behavior is undefined.

ちゃんと戻り値の項でstack overflowの可能性について言及しとりやす。

バナナ牛乳噴いた、calloc(3)の意味無さすぐる。

PHP + backslash

kbkさんとこ、PHPよう知らんのですが実装がどうなってるか次第ですね。

となってるとアウトでしょうね。

まぁWindows環境ではCP932(Windows-31J)を指定しないとそれこそ
いつものWAVE DASH vs FULLWIDTH TILDE問題なんかもありますから
script encodingにShift_JISを指定することはまず無いのでいいんじゃないでしょーか :D

Solaris 8の動作確認してみた。

bash-2.03$ printf \\x5c | iconv -f PCK -t UTF-8 | od -x
0000000 5c00
0000001
bash-2.03$ printf \\x5c | iconv -f SJIS -t UTF-8 | od -x
0000000 5c00
0000001

ふーん、どっちもバックスラッシュなのか。

やっぱりNetBSDもja_JP.SJIS捨ててja_JP.CP932を実装するべきちゅう気がしてきた。

昨日

貧血気味でふらふらしてメールの文面に詰まったまま寝落ちした。

クラウト・コンピューティング、つまり 電卓ですね?
このデュッセルドルフ派めが!

[NetBSD] new locale db into 5.0

何とか某所宛てのメール書いた、というかロスタイム笛鳴ってるという。
nviのpatchの方もあとはlong long使ってるよなkludgeを微修正するだけなので
誰か引き受けてちゅう事にした。

んでMD CHAR_MAX対策もてきとーに 突っ込んだ
そろそろlibcへのpatchとして作り直さんとな。

2008/10/31(Fri)

[NetBSD] 5.0

tagうたれたな。
new locale dbは結局pullup requestで5.0へちゅーことになった。

どうすっかなーfixsa枝みたいに5.0枝に対して枝切るのもアレだし
HEADにfixlocale枝とか切ってHEADにmerge、その後pullupするのかな。

ちゅうかlibcへのmergeだけなら別に枝切るような量じゃないんだけど
src/share/localeあたりがな。

つかあの「まるでそびえたつピーの山」をメンテするのかぁ、げんなり。
LC_CTYPEだって結構チェックしんどかったんだけどな。

libc側だけつっこんでlocale dbは放置したくなってきた。
そもそもmultibyte regexないからmutibyte locale圏はLC_MESSAGESの動作がアレになるし。

これを各カテゴリごとに書き直してチェック表にすっかいな。