2003/04/01(Tue)
○ Citrus XPG4DL for OpenBSD
20030401版を用意しますた。
変更点
- distrib/sets/lists/base/md.${ARCH} の記述で lib${ENCODING}.so のバージョンが4.0のままだったのを4.1に修正
- タグが打たただけで正式なリリースではないが OPENBSD_3_3 ブランチ向けのパッチも用意
既に導入済の人はアップデートする必要ありません、新機能はいっさい無いです。
20030401版を用意しますた。
変更点
既に導入済の人はアップデートする必要ありません、新機能はいっさい無いです。
調べてみりゃつまんない理由ですた。
Index: lex.l
===================================================================
RCS file: /home/cvs/NetBSD/src/usr.bin/mklocale/lex.l,v
retrieving revision 1.8
diff -u -r1.8 lex.l
--- lex.l 10 Mar 2003 21:18:50 -0000 1.8
+++ lex.l 3 Apr 2003 07:54:20 -0000
@@ -84,11 +84,11 @@
'\\v' { yylval.rune = '\v';
return(RUNE); }
-0x{XDIGIT}+ { yylval.rune = strtol(yytext, 0, 16);
+0x{XDIGIT}+ { yylval.rune = strtoul(yytext, 0, 16);
return(RUNE); }
-0{ODIGIT}+ { yylval.rune = strtol(yytext, 0, 8);
+0{ODIGIT}+ { yylval.rune = strtoul(yytext, 0, 8);
return(RUNE); }
-{DIGIT}+ { yylval.rune = strtol(yytext, 0, 10);
+{DIGIT}+ { yylval.rune = strtoul(yytext, 0, 10);
return(RUNE); }
uint32_t v = (__nbrune_t)(wchar_t)v として扱うのであれば
result = LONG_MAX errno = ERANGEで32bit目が
落ちてしまうstrtolではダメ。strtoulでつな。
なんとか時間作って週末までにはzh_CN.GB18030.srcと一緒にsend-prする予定。
それが終ったら次はHZ+(ある程度できてるんだけど)ですな。
せぐぽって落ちるな。 __nbrune_tをuint32_tにするのを忘れてたわ。
こりゃ動くようにするの大変だわ...
とりあえずwchar_tを32bit clean にするpatch。近いうちに投げます。
投げマスタ
FreeBSDだとこんな感じ。
http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/gdtoa/
ノーコメント。
patchはapproveされますた。
jkh%apple.comさまがCitrusに興味を持たれたようです(AA略)
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=8968+0+archive/2003/freebsd-i18n/20030309.freebsd-i18n
tjr%freebsd.org(FreeBSD C99 project)はperforceでこんなことやってたのね。
http://perforce.freebsd.org/dtb.cgi?FSPC=depot/user/tjr/wchar/src&HIDEDEL=NO
こいつを-currentにmergeするのが既定路線の模様、まあなんつーかノーコメント。
こっちには書いてなかったけど、
up してありんす。
gbk2k moduleとzh_CN.GB18030サポートが新機能。
これも古いネタだけど
http://www.deadly.org/article.php3?sid=20030206041352
なんてのをハッケソ。FreeBSDのsrc/lib/libc/localeを移植したものですな。
ちなみにCygwinやeCosで使われてるnewlibっていうlibc実装(元々NetBSD由来)も
FreeBSDのlocaleまわり(ほんの一部だけんど)突っ込まれてたりしてたりもする。
なじぇNetBSD/CitrusでなくFreeBSD/runeを移植する人が多いのかを考察してみると
 ̄ ̄ ̄ ̄ ̄∨ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ /\ /\ /神\/../ / /\ \(´∀` )./ ())ノ__ ○二○二⌒/../ / /||(二ニ) (___/../ 几l γ ⌒ /|?V||彡Vミ/⌒_ノ二二ノl0 l| (◎).|l |((||((゜ )/⌒/||三三三・) || (´⌒(´ __ ゝ__ノ  ̄(___) ̄ ゝ__ノ≡≡≡(´⌒;;;≡≡≡  ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄(´⌒(´⌒;; >>NetBSDへ OS XのlibcはFreeBSDですが何か?(ププ >>OpenBSDへ 200万ドルの件は残念だったな(ププ
ってとこなんじゃないかなと。
Citrus
iconvの登場で形勢は逆転するかもしれんけどナー。
自分で書いたgbk2kくらいはiconvdata書かにゃね。
OpenBSDへの移植も特に問題ない様子、
書き換えたのは<sys/stat.h>とかgetprognameとかそんぐらい。
週明けくらいにはpatchを用意します。
# foo.mps.src
TYPE mapper_std
NAME foo/bar
SRC_ZONE 0x0-0xfffffffe
DST_INVALID 0xffffffff
DST_UNIT_BITS 32
BEGIN_MAP
0x0-0xfffffffe = 0x0-
END_MAP
$ /usr/bin/mkmapper_std < foo,mps.src >foo.mps
malloc: Cannot allocate memory
うーむ、alloc_table()で死んでしまう。
上の例は極端かもしれんけど、GB18030-2000のバヤイ
ASCII/GBK compatible areaを別CSIDにしたとしても
SRC_ZONE 0x81308130-0xfe39fe39
とか無駄に大きなtableが必要なので、GB18030-2000ヤバい。
まじでヤバイよ、マジヤバイ。mallocできないくらいヤバイ(以下略
してもメモリ192MBな開発用ノートでわKilledされてまうわー。
src/usr.bin/mkmapper_std/yacc.y修正ですかぁ。
ここ。
iconvdata書いてNetBSD/Citrus projectにcontribしてあげてくらはい。
すっかりさぼってます。
mkiconv_gbk2k/mkmapper_gbk2kを作るのが正解のような気がしてきた。