The Man Who Fell From The Wrong Side Of The Sky:2007年5月分

2007/5/1(Tue)

連休

@ 28〜30日まで

ひたすら本読んでDVD観ての生活。

偏りすぎ。

それにしても Apollo 13のKen Mattinglyがフサなのにはいつも違和感が。
Tom Hanksいうところの「1/5の嘘」ってやつですか?

@ 今日

会社にきたら誰もいなかった orz 今年9連休だったのね。
ちょびっと仕事して帰る。

pkgsrc/print/cups

$ uname -sm
Linux i686

なのにlibcups.soがlib64以下にインストールされてしまうのはなんでだろ。

2007/5/5(Sat)

連休

@ 2〜3日まで

大学時代の友人とン年振りに渋谷でスタジオ入り、Trashcan SinatrasとAztec Cameraから数曲演った。

@ 4〜5日まで

相変わらずSpace Race関係の本読んで過ごす。

Wally Schirra死去。

OpenBSD

4.1でたのか、Citrus patchも更新しなきゃなぁ。

2007/5/6(Sun)

[NetBSD] src/sys/compat/compat_util.[ch]

のemul_find() -> emul_find_root()の変更でsrc/sys/lkm/execあたりが壊れてる >>4.99.19
patchは こんなかんじ。

2007/5/8(Tue)

[NetBSD] kern/36287

dsl@のお返事の意味がよーわからんちん。

The fix is to exclude the object file containing find_emul-root() from
the LKMs.  I thought I'd done that.

ぇー?

$ nm /netbsd | grep emul_find_root
c073aef0 T emul_find_root
$ nm /usr/lkm/exec_linux_elf.o | grep emul_find_root
000007bc T emul_find_root

やってないじゃん、なんか俺勘違いしてる?

というこれまでの方法を踏襲したpatchを送ったつもりなんだがなぁ。
これをcompat_util.cをoptions LKMの場合は常にkernelにlinkするようにして
それぞれのlkm moduleにはcompat_util.cを含めないようにすべきってことかね?

2007/5/13(Sun)

[NetBSD] 続 kern/36287

修正入った。
でもこれだけだとkernel configでcompat系のoptionsを全て切ってると
kernelにはcompat_util.oがリンクされなくなる。される模様、 ここ参照。
そうするとmodloadした時にundefined symbolだし駄目だよなぁ。
libcompatもlibkernと同様にoptions LKMが指定されている場合は
COMPAT_AS=objをセットしてlibcompat.aでなくlibcompat.oとしてbuildしないと。

--- Makefile.i386.orig	2007-05-13 21:05:58.000000000 +0900
+++ Makefile.i386	2007-05-13 21:06:14.000000000 +0900
@@ -39,8 +39,10 @@
 ##
 .if !empty(IDENT:M-DLKM)
 KERN_AS=	obj
+COMPAT_AS=	obj
 .else
 KERN_AS=	library
+COMPAT_AS=	library
 .endif
 
 ##

[NetBSD] libcompat.o

う、COMPAT_AS=objじゃ駄目ぽ。

making sure the compat library is up to date...
make: don't know how to make libcompat.o. Stop

make: stopped in /usr/src/sys/arch/i386/compile/NO_COMPAT/lib/compat
*** Error code 2

Stop.
make: stopped in /usr/src/sys/arch/i386/compile/NO_COMPAT

[NetBSD] COMPAT_AS=library

compat系のoptions全部外してみたけど、exec_elf32.oがemul_find_intrp()を呼んでるおかげで
libcompat.aのままでもcompat_util.oはちゃんとkernelにlinkされる模様。
メンドいしこのままcloseするかな...

2007/5/17(Thu)

[OpenBSD] citrus patch

作業中の ブツ
2〜3日中にはちゃんと仕上げて配布物を作るのでしばしおまちを。

とつか再開発くん

どうみても「人生オワタ\(^o^)/」にしか見えんこのやる気のない キャラ
最近駅前でやたら見かけてツボに入ってたんだがやっぱり 一部で評判になってたらしい。
流石はWim Wendersの名作 「パリ、テキサス」の続編 「原宿、戸塚」の舞台(ぉ

[豆知識]
かつて戸塚にあった遊園地「ドリームランド」の名前の由来は、同名の占領軍特殊慰安所。
まるで Joy Divisionですな。
つまり人生オワタ=Ian Curtis、とつか再開発くん=New Orderだったんだ(AA略

洋楽オタしか判らんネタですいまそ。

2007/5/18(Fri)

[FreeBSD] ja_JP.eucJP

http://www.freebsd.org/cgi/query-pr.cgi?pr=51085 ネタ。

問題になってるisprint(3)の挙動だけど
multibyte文字の1byte目だけ食わせればそりゃ0になりますわな。
mbrtowc(3)でwchar_tに変換してiswprint(3)を使いまひょう。 *1

つーわけで普通はi see no evil〜 *2なんだけれどもacceptされてるよ、おい。

何か弄るならsrc/lib/libc/locale/euc.cでSS2/SS3を扱えるように直せばいいのにねぇ。
(追記) 塩崎さんからツッコミ、SS2/3は対応しているそうです。

*1:まあls(1)はfilesystemのi18n/m17nが絡んでくるのでいろいろと(以下略
*2:よく声がTom Verlaineに似ていると言われますが何か? orz

2007/5/22(Tue)

[FreeBSD] 続 ja_JP.eucJP

utf-8使えってことですかねより。

いや別にja_JP.eucJPがFreeBSDから無くなったとかという訳ではないので安心してください。
ja_JP.eucJPの定義が一部壊れただけです、今回の変更をbackoutすれば何の問題もないんですけどね。

FreeBSDの実装だと半角カナの2byte目をisprint(3)に食わせたときに0にならない件を塩崎さんが指摘されてますが
これを保障しようとするとShift_JISの場合困るんで、まあ1byte目以外の挙動は
undefinedのケースでいいんじゃないかと私は思います。 *1

今回の(普通ならrejectされるべき)patchをacceptしたのがache@ってんで「ああ、やっぱり」というのが今回の話のキモ。
この人はFreeBSDのi18n周りの責任者を長年務めてる人で、LC_COLLATE他の実装をした人なんですが
ちょっと知識が古いつーかなんつーかでして。

CitrusをFreeBSDにmergeしようとした時のの彼の反応で判って頂けるかなぁ。

            / ̄ ̄ ̄ ̄ ̄\
         /           \
         /              ヽ
   / ̄\ l      \,, ,,/      | 
  ,┤    ト |    (●)     (●)   | Citrusは標準APIじゃないお!!実装する価値ないお!!
 |  \_/  ヽ     \___/     | (いってやった、いってやった)
 |   __( ̄ |    \/     ノ
 ヽ___)


   . . .... ..: : :: :: ::: :::::: :::::::::::: : ::::::::::::::::::::::::::::::::::::::::::::: 
        Λ_Λ . . . .: : : ::: : :: ::::::::: ::::::::::::::::::::::::::::: 
       /:彡ミ゛ヽ;)ー、 . . .: : : :::::: ::::::::::::::::::::::::::::::::: 
      / :::/:: ヽ、ヽ、 ::i . .:: :.: ::: . ::::::::::::::::::::::::::::::::::::::: 
      / :::/;;:   ヽ ヽ ::l . :. :. .:: : :: :: :::::::: : :::::::::::::::::: 
 ̄ ̄ ̄(_,ノ  ̄ ̄ ̄ヽ、_ノ ̄

大ちゃん…ISO/IEC 9899/{AMD1:1995,1999}とIEEE Std 1003.1くらい読もうよ…

つー感じで、いやぁ相変わらずだなぁという。

*1:wchar_tによってi18n化されてないけど、8bit through(=unsigned char)なプログラムで
なんとな〜く日本語(EUC-JP)使える状態にするには保障した方が幸せなのかもしれんけど。

[i18n] pkgsrc/converters/libiconv

現場のLinux(FC2) + pkgsrcで動かしてるファイルサーバなんだけど
pkgsrcのGNU libiconvが1.10 -> 1.11になったときに
legacy-encoding projectのpatchがkillされたせいでsambaがちとマズイことになってた。
3ヶ月近く気付かず放置してたがキニシナイ。

EUCJP-MS -> UTF-8にするのもメンドイので1.11用のpatchをでっちageしてみた。
/distfiles/GNU/libiconv/libiconv-1.11-ja.patch.gz
LE本家の方が対応するまでの暫定ということでひとつ。

@ 2007/11/09 追記

LE本家で対応されたみたいなので消しました。

[SCM] Subversion

$ svn mkdir file:///path_to_svn_repository/{trunk,branches,tags}

という書式も受け付けることに今更ながら気付いた、bashismがこんなところにまで。

2007/5/23(Wed)

[NetBSD] kern/36370

http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=36370
kernel iconvマダー? ネタ。
変換テーブルをkernelに抱え込まないようにuserlandにiconvd(8)置いて
/dev/iconv経由でkernelとお話とかするとさすがに遅いんでしょうか。
いやよう知らんけど。

いっそmsdosfsをpuffs/FUSEにしてしまえばlibcのiconv(3)呼び放題だったりするのかもしれん。

2007/5/25(Fri)

[OpenBSD] http://www.openbsd.org/

アクセスすると403 Forbiddenになてる、謹んでご生前の(以下略)
cvswebは生きてるんだけど一部のソース消えてるげ、何かアナウンスあったっけ?

[NetBSD] u_int32_t vs uint32_t

@ きっかけは

Citrusのコードで両者が混在してるのでちょっとお掃除しようかと思ったのだが
どっちを使うのが正しいのか判らんので調べてみる。

@ 調査結果

NetBSDが移植性の為にu_int32_tを導入したのが1994年。
<machine/types.h> rev1.3

んでhtonl(3)の引数がunsigned longに変わってu_int32_tに変更されたのが1996年。
<machine/endian.h> rev1.17*1

その後、htonl(3)はSUSv2(Single UNIX Specification version 2)に 取り込まれる
この時インタフェースが<sys/types.h> u_int32_tではなく、<inttypes.h> uint32_t に変更されている *2、1997年頃なのかなぁ。

ちなみにPOSIX(IEEE Std 1003.1-2004)/C99(ISO/IEC 9899:1999)ではuint32_tは
<stdint.h>に移されて<inttypes.h>は<stdint.h>をincludeすると改められる、変更の

NetBSDがPOSIX/C99対応の為に<inttypes.h>および<stdint.h>そしてuint32_tを導入したのが 2001年。
<sys/types.h> rev1.49

そして同時期にntohl(3)のSUSv2でのインタフェース変更をNetBSDに取り込んでいる。
<sys/endian.h> rev1.4
これはPOSIX互換(_POSIX_SOURCE)の場合のみで、それ以外はu_int32_tがこれまで通り使われている。

しかしこれは後に完全にuint32_tに置き換えられる、2005年の出来事。
<sys/endian.h> rev1.19
つまりPOSIX互換やC99互換(__STDC__ && __STDC_VERSION__ >= 199904L)のどちらでもない
ソースの場合でも、<sys/types.h>をインクルードすればuint32_tを使って構わないつーこと。

これを私は「u_int32_tからuint32_tへの置換を推奨する」と読んだんだけどどうだろう。
NetBSDの場合

typedef uint32_t	u_int32_t;

となっててu_int32_tはuint32_tの別名扱いだし、そもそもu_int32_tおよびuint32_tに対応するsigned型は
どちらもint32_tになってしまうので別物として扱うと話がややこしくなりそうだし。

一方FreeBSDでは

/*
 * XXX POSIX sized integrals that should appear only in <sys/stdint.h>.
 */
...
#ifndef _UINT32_T_DECLARED
typedef __uint32_t      uint32_t;
#define _UINT32_T_DECLARED
#endif
...
typedef __uint32_t      u_int32_t;

と、u_int32_tとuint32_tは別定義になってるし(まあ実体はどちらも<machine/_types.h> __uint32_tだけどさ)
ご丁寧にuint32_tには「XXX」なコメントまでつけてある。
なのでuint32_tとu_int32_tはちゃんと使い分けろといってるように見えるんだよね。

@ 結論

カレーとカリーぐらいの違いなので気にするだけ無駄だおwwwwwwwwwwwwwww
ちょっとemacs -e doctorしてきますね。

*1:この後backoutされたり、XPG4(X/Open Portability Guide Issue 4)に合わせてin_addr_tに変更された時期もある模様。
*2:OpenBSDの<sys/endian.h>やmanpageは未だにu_int32_tのままですな。

2007/5/28(Mon)

[FreeBSD] TODIGIT

塩崎さんとこより。

あれ?TODIGITってdigittoint(3)で使ってたと思うんですが…記憶違いかな。
# なんで消すと非常にマズイ気がするんですけど。

まあNetBSDの場合はdigittoint(3)は無いので消してもいいんでしょうが
同等の機能が将来的にlocale awareな{str,wcs}to{l,ll,imax,ul,ull,umax}(3)の実装とか
vf(w)printf(3)の%I実装(GNU拡張ですけど)にも必要になる予感。

記憶が正しければFreeBSDは{str,wcs}to{l,ll,imax,ul,ull,umax}(3)の実装に
既にdigittoint(3)を呼んでたかと。
# ただし[0-9A-Fa-f]の範囲までしか変換できないので(本当は[0-9A-Za-z]まで必要)
# 役に立たないのでコメント化されてた記憶が。

2007/5/29(Tue)

[OpenBSD] __weak_alias(alias,sym)

cpp マニアックスで思い出したんだけど、OpenBSDとNetBSDの__weak_alias(alias,sym)のちょっとした違いの話。

NetBSDの場合

となってるので

のどちらの書き方も可能なのだけれども、OpenBSDの場合

という定義になってるので、リンク先にある通りの理屈で
前者のソースをgas assemblerに落とすと

	.file	"test.c"
#APP
	.weak _foo ; _foo = _foo
#NO_APP
	.text
	.globl	_foo
	.type	_foo, @function
_foo:
...

と展開され、fooシンボルが消えてしまう。
これでは__weak_aliasする意味がないのでびみょーに注意、つかこれバグ(以下略

ちなみにFreeBSDだと__weak_reference(sym,alias)というのが同等のマクロ。

__weak_alias(alias, sym)とは引数が逆なので注意。

2007/5/30(Wed)

[OpenBSD] Citrus patch

RC1
MB_LEN_MAX 32 で壊れるバイナリ後方互換は
正式版に対策用のパッチ(以前のrename.patch)も含める予定。

2007/5/31(Thu)

[NetBSD] Citrus iconv

CP1046(Arabic Extends)とCP1124(Cyrillic, Ukraine)の変換表書いた。
cvs復活したらcommitすんべ。

ところでGNU libiconvとJava6のCP1046の変換表って間違ってないか?
アラビア基本形(U+0600-U+06FF)ではなくてアラビア表示形B(U+FE70-U+FEFE)
の方を使うべきだと思うんだが(実際CP864の変換表はそうなっている)。

それとCP{864,1046}(表示形B) -> ISO8859-6(基本形)の変換では
前者は後者に包摂されることになるよなぁ、これもそのうち直さんと。

最近買った本