○[FreeBSD] _FileRuneLocale

FreeBSDのsrc/lib/libc/locale以下久しぶりに眺めてたら、いつの間にやらCitrusと同じように

• _RuneLocale(wctypeなどが使う)
• _FileRuneLocale(LC_CTYPEファイルを読込む時だけ使う)

に分割してたのね。
まあこれやらんとFreeBSDは/usr/share以下にLC_CTYPEファイルを置いてるにも関わらず
sizeof(long)やendianの異なるarch間でNFSなどで共有できないとゆー大問題があったのだけども。
このへんの議論参照ね。

ググってみたら 6.0-RELEASEで対応したのね。
s/long int/int32_t/g及びbyteorder(3)でfile formatが変わってしまうので
/usr/share/locale/*/LC_CTYPEの後方互換性が失われてしまう件については無視かYO！と思ったら
ports/misc/compat5xに含まれるlibcで変更後のformatを読めるように対応して回避してる模様。
まあlibcをstatic linkしたbinaryのバヤイはこれでも葉亜駄目大(by 花輪和一)なんだがね。
FreeBSDはもういっそ/usr/libdataにするしかないだろJKと思ってたんだけどモナ。

我が身振り返るとlocale databaseやiconv databaseをMIとして/usr/shareに置いてる
NetBSDも他人事じゃないのよな、例えば以前から放置状態のTODO

• OOB_MODEの改善
• UCS%*の無駄領域喰い問題
• mapper_zoneの改善

あたりを真面目にやろうとした場合、iconv databaseのformat変更が必須になりそうなのよね。
format変更が必要になるのが新しく追加するCES(*.esdb)/CCS(*.mps)だけならまだしも
(実際問題、GB18030の4byte領域のサポートの時は 変更したしね)
既存のCES/CCSが使えなくなるのは青汁のようにとっても不味い。

最近はpkgsrc/emulators/compat40とかのパケージが整備されてるので
libc static linked binaryの事を忘れてしまえばFreeBSDと同じ逃げ方もできるのだけども。
実際libpthreadがらみでもうNetBSDはfull dynamicaly rootなのだから
今更statically linked binaryなんか使う奴わチネと公言する人もいるわけだし。

まあ現実問題Citrusはdlfcn(3)に依存してるのでstatic linked binaryのこたスッパリ忘れておｋなのだが
DragonFlyBSDなんかはjoerg氏が独自にstatic linked binaryサポート入れてたりする事も考えると悩むな。

というわけで動いてるものは触らずに放置なわけです、はい。

linux emulationみたいに/usr/pkg/emul/netbsdにchrootするか(笑)

○ PHP(以下略

エミネムの8 mileとか見たほうがいいよ
ヒプホプのdis合戦のやり口を分かりやすく説明しているから

とゆーしょーもないネタしか思いつきません。
今ならオマケで2PAC、金利手数料は(ry じゃーぱねっと。

ソフトウェア開発とは関係ないけども、内輪受け＋悪乗り文化圏では
空気嫁ることと自重できることはじゅーよーな資質ではあると思う。