Not only is the Internet dead, it's starting to smell really bad.:2006年04月分

2006/04/03(Mon)

tech-userlvel

unicodeに変換できる文字か否かを調べるのにwchar_t interfaceを使えというのはちょっとなぁ。
STDC_ISO_10646が常に正しいと言質を与えかねない悪寒、いまさらですか?

無理矢理POSIX localeで片付けようととするとこんな感じ↓かなぁ。

#include <wctype.h>
wchar_t wc;
wctype_t wctype;
mbstate_t ps;
const char *s;
size_t n;

setlocale(LC_CTYPE, "ja_JP.eucJP");
s = ...
n = ...

mbrtowc(NULL, NULL, 0, &ps);
wc = mbrtowc(&wc, s, n, &ps);
wctype = wctype("ucs4-compaliant");
if (iswctype(wc, wctype) != 0) {
   .../* ucs4の文字だよ */
}

wctypeのユーザ定義クラスに"ucs4-compaliant"を用意しろとかwwwwうはwwwヒドス

結局「libxml2が全部自分でやれ」「GNU libiconvの未定義動作依存ならpkgsrcで
そっちDEPENDすれば?」という身も蓋も無い意見しか思いつかないのでしばし静観。

@

まあiconvに渡す前に一旦mbrtowcに食わせて様子を見れば
(mbrtowcで)EILSEQになるか(iconvで)EINVALになるかの区別はつくかも。
その意味でのwchar_t interface使えかね。

ただしmbrtowcの実装はそのコードポイントに実際に文字が割り当てられてるか否か
厳密にチェックしていないのでそれは問題になるかも。

それとPOSIX localeはreentrantじゃないので
現実的にはmbrtowcでは問題有りだよな。
それにそもそもUTF-16/32はmbrtowcの実装はできるけど
isalphaなどで問題有るからPOSIX localeでは扱えないジャマイカ

2006/04/04(Tue)

続tech-userlevel

libxml2のソース斜め読み。
NetBSD/Citrusでもiconv(1)の実装にはiconv(3)のinterfaceじゃ不足があるので
invalid character countを拾うか否かのフラグをセット可能な__iconv(3)を使ってるから
これをlibxml2でも使う(__ICONV_F_HIDE_INVALIDフラグに追加して
__ICONV_F_STOP_INVALIDを実装)、あるいはiconvctl()を実装するかでいいんジャマイカ。

@

パッチ書いた↓ もう少しテストしたらtech-userlevelに投下するかも。
/distfiles/citrus/NetBSD/patch-iconv

2006/04/10(Mon)

XREA祭り

http://www.value-domain.com/info.php?action=press&no=20060408-1 うぎゃー。

メーリングリスト関係全滅に、オークション落札メール不着wwwwwとか
かなりの痛手を喰らいましたが

                     パハ  
                   ('(゜∀゜∩ うんこしたらなおるよ!
                    ヽ  〈 
                     ヽヽ_)

うちからのERRORメールが届いた管理者の方々、本当に申し訳ありませんでした orz
転送関係は仕事用のアドレスに変更しました…

2006/04/11(Tue)

wcstod

@

gdtoaまわりが落ち着いたようなのでwcstof(3) + wcstold(3)でもと思ったら
wcstod(3)が入力文字を(以下略)することに気づいた。
あーもうやっぱりテストケース用意せんと。

OpenBSDでも直ってない、本当にコード監査(以下略)。
会社帰りのバス内でcommit。

@

DragonFlyでのCitrusのメンテナのJoerg氏から
「16進の"0x"とかNANとかこのままじゃあかんでー」とツッコミ。
ちょっとFreeBSDのコード見てみるか。

@

FreeBSDのコードを元に書き直した、つかこんな時間まで何やってんだ俺。
今週カットオーバーで毎日朝早く出社せなあかんのにorz。

2006/04/13(Thu)

wcstod(3)

テストケース書いたのでcommit。
ただし浮動小数点の16進表示の変換周りでNetBSDとLinuxのstrtod(3)にバグを発見したので
テストケース中で#ifdefがある罠。
バグというのは以前 パッチ書いたまま放置中のstrtolの バグと同じで

const char *s = "0x";
char *t;
d = strtod(s, &t);
assert(*t == 'x');

に引っかかるという奴ね。

このあたりSolarisの挙動がどーなのか確認したいのだけど、
浮動小数点の16進表記をさぽーとしてないSunOS 5.8 + ForteC 6.0しかすぐには用意できず。

まとめて投げるべ。。。

んで、strtol(3)の中で10から35に変換される[A-Za-f]のチェックにisalpha(3)を
使ってるのに気付いたけどこれはダメなような。

ロシア語のаとかもisalpha(3)にマッチしてしまうがな、パッチ作り直すか。

2006/04/14(Fri)

strtold(3)

NetBSDのstrtold(3)ってちょっと動作が変。

#include <assert.h>
#include <stdlib.h>
#include <math.h>
int main(void) {
    assert(isinf(strtold("INF", NULL)));
}

----------------------------------------
assertion "isinf(strtold("INF", NULL))" failed file "strtold_test.c", line 5, function "main"
Abort (core dumped)

うげげ。src/lib/libc/arch/i386/gen/infinityl.cを見る限り

Index: strtopx.c
===================================================================
RCS file: /cvsroot/src/lib/libc/gdtoa/strtopx.c,v
retrieving revision 1.3
diff -u -B -w -r1.3 strtopx.c
--- strtopx.c	15 Mar 2006 17:35:18 -0000	1.3
+++ strtopx.c	14 Apr 2006 13:08:44 -0000
@@ -89,7 +89,8 @@
 
 	  case STRTOG_Infinite:
 		L[_0] = 0x7fff;
-		L[_1] = L[_2] = L[_3] = L[_4] = 0;
+		L[_1] = 0x8000;
+		L[_2] = L[_3] = L[_4] = 0;
 		break;
 
 	  case STRTOG_NaN:

こうじゃないのかな...
それにコンパイラとgdtoaで丸め誤差が微妙に違う。

long double x, y;
x = 0.1;
y = strtold("0.1", NULL);
assert(x == y);

これは許容されうるものなのかね?
ちなみにRedhat9/glibc-2.3.3だとstrtold(3)が 完全に壊れてるwwwwので確認できず。

2006/04/15(Sat)

BOF

jp.netbsd.orgは復活してるようだけど一応転載。

いよいよ 明日 16日(日) NetBSD ユーザーグループ総会と NetBSD BOF の
開催なわけですが、www.jp.netbsd.org がトラブっているようなので、
こちらに開始時刻と会場を掲載しておきます。

開始時刻:
12:30~ 開場
13:00~ JNUG 総会
13:45~ NetBSD BOF

会場:
国立オリンピック記念青少年総合センター
センター棟102号室
http://nyc.niye.go.jp/facilities/d6-1.html

アクセス:
小田急線参宮橋駅より徒歩7分 / 営団地下鉄千代田線代々木公園駅より徒歩10分
http://nyc.niye.go.jp/facilities/d7.html

Web 日記や blog を持っている人は、そちらにも上記の内容を
掲載していただけるとありがたいです。
(それまでに www.jp.netbsd.org が復活していれば必要ありませんが。)
よろしくお願いします。 
--
(C) 2ch

私は都合により参加できません、申し訳ない。

wcstof/wcstold

skrll氏のリクエストでwcstof/wcstoldをつっこみますた。
前に書いたとおりstrtold(3)が腐ってるのでそっちを先に直したかったけど。

@

assert(0.1L == strtold("0.1", NULL));

はちゃんと動くな。

2006/04/16(Sun)

wcstod(3)

2重3重にorz、ビルドに失敗した方には申し訳ない。しばらくお遍路の旅に出ます。
christos氏に__weak_aliasつけ直された件は、コーディング規約にある

When to add weak-symbol to library functions? (top)

    In short, to quote Klaus Klein:

        * the identifier is to be used internally by libc, and
        * the identifier is not a feature of ANSI C resp. C90.

って-std=C89のことで、ISO-C90:AMD1は含まれないってことかな。
これ、src/libc/locale/multibyte_amd1.cにある関数にはついてないんだよな...

$ nm /lib/libc.so | grep mbrlen
000a4e10 T mbrlen

2006/04/17(Mon)

GEORGIAN-ACADEMY/GEOGIAN-PS

グルジアの文字コード。 GNU libiconvやXFree86/xorgのunicode変換表は↓をベースにしている。
http://crl.nmsu.edu/~mleisher/csets.html
ところが調べた限り、この変換表のように0x80~0x9Fに記号その他を
割り当てたフォントって見つからないんだよね(探し方が悪いのか?)

一方X-TT Projectがかつて使用していた変換表↓
http://cvsweb.xfree86.org/cvsweb/xc/extras/X-TrueType/GEORGIAN/Attic/GEORGIANtoUCS2.c
こっちは0xE6~0xFFの空き領域に記号やUnicodeに無い文字を詰め込んでいるけど
これはextendedとかalternativeという呼び名でよく見かける↓のよね。
http://members.tripod.com/shoshia/fonts.html
http://www.geocities.com/bpgfonts/index_1.htm
ただしこの変換表も細かい間違いはある模様。

0xEC = ○ U+201C × U+201F
0xEE = ○ U+10FB × ALTCHAR
0xFB = ○ PUA    × U+221E

あたりかな。

2006/04/19(Wed)

weak symbol

sodaさんから__weak_aliasの非常に丁寧な説明をわざわざメールで頂いて恐縮しております。
ありがとうございました。

まとめると

以下例題。

  1. wcstod(C90:AMD1)が内部でstrtod(C90)を呼び出すのは
    C90:AMD1 ⊃ C90
    
    なので問題なし。
  2. vfprintf(C90)がmbrtowc(C90:AMD1)を呼び出すのは
    mbrtowc ∈ C90
    
    は偽なので問題あり、weak symbol化すること。
  3. vfwprintf(C99)がmbrlen(C90:AMD1)を呼び出すのは
    C99 ⊃ C90:AMD1
    
    なので問題なし。

CP1131

昨晩放送されたNHKドキュメント:チェルノブイリ特集でも登場した
ベラルーシのIBM-DOS Codepage。
GNU libiconvの開発者bruno氏のUnicode変換表と
FreeBSDのLC_COLLATEとRFC1345を元に作ったUnicode変換表が
これまた一致しないのよね。

2006/04/21(Fri)

Trac

UTF-8 locale 以外で動かすと日付が文字化けするバグ対策パッチを更新↓
/distfiles/trac/trac_strftime_use_nl_langinfo_codeset.patch.gz
TimelineのView changes from [ ] and [ ] days back.が正常に動作するようになっています。

2006/04/24(Mon)

GEORGIAN-{PS,ACADEMY}

/diary/?20060417#17-1
の話だけど、どうやらこれWindows-1251由来の予感。

2006/04/26(Wed)

Scarab + SMTP over SSL

@

現場のメールサーバがSMTP over SSLになったのでいろんなとこに影響が。
特にバグトラックとして使ってる Scarabを大至急対策せんとね。

@

ScarabはtrunkであればSMTP認証には対応している↓
http://www.solitone.org/scarab/issues/id/SCB1197
しっかしほんとならturbine-templateを修正するのが筋だろうに。
他プロジェクトのcommons-emailを書き直してシステムプロパティに

mail.smtp.user=ユーザ名
mail.smtp.pwd=パスワード

設定されていたらSMTP AUTHするというギガヒドスwwwなやり方に全米が泣いた。

同一コンテナで別のJavaMailインスタンス動かしたり、正式版のcommons-email動かすとたちまち不幸になる悪寒。
まあそもそもcommons-emailは正式版自体が1.0-rc5 → 1.0でバイナリ互換がなくなった極悪なシロモノだけど。

んでこんな禁じ手を使ったにも関わらず依然POP before SMTPやSMTP over SSLには対応していない。
もうね(ry

@

以前From:が文字化けするバグへの対策patchを書いた時も、commons-emailの設計のお粗末さには萎えてたので、
すっぱり棄てて直接JavaMail API呼ぼうかとも思うのだが、fulcrum-templateを修正すると依存関係やらなんやらでメンドい。
よって本家のkludgeな方法を拡張してSMTP over SSLに対応してみた(From:文字化け対策も含んでます)。

@

TODO: POP before SMTP
つか環境作らんとテストできん。