#3227761で一個abortしません？
#Total: 12286 tests, 12286 passed, 0 failed, 1 aborted.
make[1]: *** [test-summary-check] Error 1
make: *** [check] Error 2
#これかな
#Testing regexp ... gosh: "error": number required, but got #f
#MacOSX 10.7.4です
#む。src/test.logの最後の部分はどうなってますか。
#最後の一行は passed. だけです
#あ、ごめんなさい。最後じゃなかった。Testing regexp の行があって、その後にTesting sort procedures って行が出てくるんですが、そのTesting sort procedures の直前です。
#regexpについての出力は全部okになってるっぽいんですけど
#test (#/((?:[0-9A-Z_a-z])+)((?:[^0-9A-Z_a-z])+)((?:[0-9A-Z_a-z])+)/ "three o'clock"), expects ("three o" "three" " " "o") ==> ok
test (#/(?:[\x09-\x0d a-c])+/ "d ba e"), expects (" ba ") ==> ok
test (#/(?:[\x09-\x0d a-c])+/ "d ba e"), expects (" ba ") ==> ok#最後の3行はこれです
#passed.が無いってことはそのテストの後でクラッシュしたってことです。むー、なにか機種依存があるのかなあ。
#grep -v 'ok$' src/test.logを眺めてるんですがまずそうなのは見えないです
#あ、なるほど＞クラッシュ
#例のipv6問題があるんで適当にしか眺めてなかったですが、Ubuntu 12.04でも一個abortしてたと思います。ちょっとお待ちを
#regexpの出力ルーチンをいじったんだけどそこでひっかかってるかな。コンパイルしたsrcディレクトリ内で ./gosh -ftest でgoshを起動して、#/[\S]/ とタイプしてみてください。
#同じく src/test.log の Testing sort procedures の前に passed. は記録されてないです。
#lolouila:maru% ./gosh -ftest [~/github/Gauche/src]
gosh> #/[\S]/
*** ERROR: number required, but got #f
Stack Trace:
_______________________________________
gosh>
#それだ。
#これっぽいですね
#私の環境(Ubuntu11.10/x86)だと動くんだよな。64bitだとまずいのかな。
#あぁ。Ubuntuは64bitです
#ちなみに #[\S] とタイプするとどうなりますか
#gosh> #[\S]
#[\-\x08\x0e-\x1f!-\x7f-?????]
gosh>
#解釈の仕方が判らないですが
#ああそれはunicodeのU+ffffffが生で出力されてるせいです。U+0080も出てるんだけど見えてないだけかな。
#あ、そもそもU+ffffffなんて無いか。あれ、U+10ffff以上が出力されちゃてるからおかしくなってるのかな。でもそれなら32bit関係ないだろうしなあ。
#ちょい出てきます。
#了解です
#--- a/src/char.c
+++ b/src/char.c
@@ -195,7 +195,7 @@ SCM_DEFINE_BUILTIN_CLASS(Scm_CharSetClass,
static void charset_print_ch(ScmPort *out, ScmChar ch, int firstp)
{
- if (ch == '[' || ch == ']' || ch == '-' || (ch == '^' && firstp)) {
+ if (ch < 0x80 && (strchr("[]-\\", ch) != NULL || (ch == '^' && firstp))) {#のせいで、ch が 0 のとき %c で出力されちゃってるんではないでしょうか。
#Scm_Printf(out, "\\%c", ch);
#もう一行ペーストしないと話がつながらなかった。
#strchrってch==0でもヒットするんだっけ? ただ、上のバグは別のところです。charsetの上限をちゃんと切ってなかったので、64bit architectureでchar->ucsが#fを返すレンジの文字が紛れ込んでしまっていたのが原因。
#If c is `\0', strchr() locates the terminating `\0'.
#て NetBSD のマニュアルには書いてあります。
#おお、そういえば何十年も前にそれに引っかかったことがあったような気がする。
#正確にはcharsetの上限は今#\uffffffになってて、32bitマシンでは(read-char (open-input-string (string #\uffffff)))とするとちゃんと#\uffffffが返るんだけど、64bitマシンではコード#xffffffffffffff という値が返ってる。文字列上のutf-8エンコーディングは正常。string->listでも正常。read-charが怪しい。
#この際全部#\u10ffffまでに制限すれば一挙解決だけど、何となく将来の拡張の余地を残しておきたいとか思って上限を大きくしている。
#わかった。#define SCM_MAKE_CHAR(ch) SCM_OBJ((long)((ch) << 8) + 3) でchが#xffffffだと、キャストの段階で負になっちゃうんだ。
##ふーむ、stackoverflowみたいな感じなのかな。とりあえず回答してみました。
#しまった、util.matchに関する質問なのにutil.matchを使う回答になってないや。
#ありがとうございますー。Stack Overflow の日本語版を目指しているようですね。
Gauche > Archives > 2012/06/07