K.Maebashi's BBS

Vine Linuxでの　echo $LANG の実行結果は ja_JP.eucJP でした。 UTF-8版がエラーとなり、 EUC版がうまくいったのはたまたまLANG環境変数が一致したからですか? 大変勉強になりました。 以上

こちらはVineLinuxでLANG環境変数がja_JP.UTF-8な環境で試してみました。 ちょうど青餓鬼さんと逆に、test.dkmはUTF版では正常動作し、EUC版では Assertion failure (wc_format != NULL) file..error.c line..92 wc_format is null. Assertion failure (wc_format != NULL) file..error.c line..92 wc_format is null. アボートしました とのメッセージが出ました。当然といえば当然の結果ですね。 これは納得が行きましたが、あとは青餓鬼さんが前に書いていたMacの結果だけが気になりますね（文字コード以前に、素のバイト列のままだった）。 むし返すようで申し訳ないんですけど、Macでの環境変数LANGは何だったのか、 よければ教えてもらえませんか。

>UTF-8版がエラーとなり、 >EUC版がうまくいったのはたまたまLANG環境変数が一致したからですか? たまたまというか、たいていのLinux環境はEUCかUTF-8のどちらかであり、 それに対応するためにふたつの配布パッケージを用意しているわけです。 ところで青餓鬼さんにお願いですが、この掲示板で誰かの投稿に返信する際は、 「新規投稿」リンクではなく、対象の投稿の「返信」リンク(右上にあります)を 使っていただけないでしょうか。 「スレッド順インデックス」で見たときに、応答の流れが見えますので。 http://kmaebashi.com/bbs/thread.php?boardid=kmaebashibbs

初めて投稿します。 Cソースの静的解析ツールを作成したくて、参考になる物を探し続けて やっとこのHPにたどり着きました。ありがとうございます。 自分の使っているサーバの環境ですが、ちょっと変わっています。 PCでソースを編集し、solarisでコンパイルする事になっています。 なので、漢字コードがSJISになっております。 LANG環境変数＝ja_JP.PCK そこで、もちろんなんですが、EUC版もUTF-8版も下記エラーになってしまいます。 どの様に対応したらよいのか教えて頂けないでしょうか？ お手数をおかけして申し訳ありませんが、 よろしくお願いいたします。 >Assertion failure (wc_format != NULL) file..error.c line..92 >wc_format is null. >Assertion failure (wc_format != NULL) file..error.c line..92 >wc_format is null.

はじめまして。 >なので、漢字コードがSJISになっております。 > >LANG環境変数＝ja_JP.PCK > >そこで、もちろんなんですが、EUC版もUTF-8版も下記エラーになってしまいます。 >どの様に対応したらよいのか教えて頂けないでしょうか？ crowbarやDiksamのソースコードで、SJIS版、EUC版、UTF-8版の違いは 以下の通りです。 (1)error_message.cの文字コードが違う。crowbar, Diksamともに、 　エラーメッセージは日本語で出ますし、そのメッセージはerror_message.c内に 　埋め込まれています。エラーメッセージも表示前にwchar_tに変換するのですが、 　この変換でエラーになっているというのが現状です。 (2)(コンパイラの)Makefileの中に-DEUC_SOURCEとか-DSHIFT_JIS_SOURCEとかの 　指定が入っている。SJISでは、「表」のように2バイト目に0x5Cを含む 　文字が存在しうるので、いわゆる0x5C問題が起こります。これを回避する 　コードが入っています。(-DEUC_SOURCEと-DUTF8_SOURCEの動きは同じです) 　これを使用しているのはcrowbar.lまたはdiksam.lです。 (3)お使いのコンパイラがgccの場合は、gcc自体の0x5C問題に引っかかるので、 　SJIS版(Windows版)のerror_message.cでは、随所に\が入っています。 　Windows版のerror_message.cを使うか、gccのオプション指定をする必要が 　あります。 というわけで、対策は以下のようになるかと思います。(試していません) ・error_message.cの文字コードをSJISにする。必要に応じて\を入れて 　0x5C問題に対応するか、gccのオプションを指定する。 ・Makefileの-DEUC_SOURCEとかになっているところを「-DSHIFT_JIS_SOURCE」に 　変更する。 Windows版のソースを参考にされるとよいのではないかと。

素早い回答ありがとうございます。 連絡が遅れてすいませんでした。 >(2)(コンパイラの)Makefileの中に-DEUC_SOURCEとか-DSHIFT_JIS_SOURCEとかの >　指定が入っている。SJISでは、「表」のように2バイト目に0x5Cを含む >　文字が存在しうるので、いわゆる0x5C問題が起こります。これを回避する >　コードが入っています。(-DEUC_SOURCEと-DUTF8_SOURCEの動きは同じです) >　これを使用しているのはcrowbar.lまたはdiksam.lです。 Makefile を　-DSHIFT_JIS_SOURCE に変更しました。 errror_message.c は、iconv で変換しました。 コンパイラはgccを利用していますが、コンパイルも問題なく通りました。 例の場所でのエラーは回避できました！ ありがとうございます。 diksamは、ちょっと進んで、コンパイルエラーが出てとまりました。 「int a; 」　だけのテストプログラムなんですが・・・ これから、GDBで詳しく調べていきます。 わからない事があったら、またお願い致します。 ありがとうございました。

先日は、Solaris＋SJISコードで動作させる為の環境構築の方法を教えて頂いてありがとうございました。 やっとDIKSAMが、マルチバイト無しの正常系が動作し始めました。 まだ、マルチバイト無しのエラー系は完璧には動作していません。 ##################### int a=0; if(a==0){ println("CCCC"); ##################### このソースと全く同じではありませんが、「｝なし」のエラーを狙いテストしますが、 EUC版は、「文法エラー($(token)付近)」　が出力されます。 自分のSJIS環境では、「不正なマルチバイト文字です。」と なってしまいます。 そこで、つっかえている所がマルチバイトの読込み辺りだと当たりがつきます。 また、自分の構築している環境では、マルチバイトが処理出来ていません。 字句解析(lex)でのマルチバイトの読込みがまだうまく出来ていないからだと思っています。 ちゃんと調べてもいないのに質問して申し訳ありませんが、教えてください。 以下の箇所は、EUC版もWINDOWS版(SJIS)も違いがありませんが、コード系関係なく同じで構わないのでしょうか？ 自分の構築したい環境でなにか考慮すべき所はありませんでしょうか？ <STRING_LITERAL_STATE>[\x81-\x9f\xe0-\xef][\x40-\x7e\x80-\xfc] { dkc_add_string_literal(yytext[0]); dkc_add_string_literal(yytext[1]); } <STRING_LITERAL_STATE>. { Encoding enc = dkc_get_current_compiler()->source_encoding; dkc_add_string_literal(yytext[0]); if (enc == SHIFT_JIS_ENCODING && ((unsigned char*)yytext)[0] >= 0x81 && ((unsigned char*)yytext)[0] <= 0x9e) { BEGIN SHIFT_JIS_2ND_CHAR; } } <SHIFT_JIS_2ND_CHAR>. { dkc_add_string_literal(yytext[0]); BEGIN STRING_LITERAL_STATE; }

すみません、回答遅れております。 その場所はencがSJISであるかどうかで動きが変わるのですが、それを決めているのはMakefileの-DSHIFT_JIS_SOURCEとかです。 今は携帯で辛いので詳細は今夜に。 >先日は、Solaris＋SJISコードで動作させる為の環境構築の方法を教えて頂いてありがとうございました。 >やっとDIKSAMが、マルチバイト無しの正常系が動作し始めました。 >まだ、マルチバイト無しのエラー系は完璧には動作していません。 >##################### >int a=0; > >if(a==0){ > println("CCCC"); >##################### >このソースと全く同じではありませんが、「｝なし」のエラーを狙いテストしますが、 >EUC版は、「文法エラー($(token)付近)」　が出力されます。 >自分のSJIS環境では、「不正なマルチバイト文字です。」と >なってしまいます。 > >そこで、つっかえている所がマルチバイトの読込み辺りだと当たりがつきます。 > >また、自分の構築している環境では、マルチバイトが処理出来ていません。 >字句解析(lex)でのマルチバイトの読込みがまだうまく出来ていないからだと思っています。 > >ちゃんと調べてもいないのに質問して申し訳ありませんが、教えてください。 >以下の箇所は、EUC版もWINDOWS版(SJIS)も違いがありませんが、コード系関係なく同じで構わないのでしょうか？ >自分の構築したい環境でなにか考慮すべき所はありませんでしょうか？ > ><STRING_LITERAL_STATE>[\x81-\x9f\xe0-\xef][\x40-\x7e\x80-\xfc] { > dkc_add_string_literal(yytext[0]); > dkc_add_string_literal(yytext[1]); >} ><STRING_LITERAL_STATE>. { > Encoding enc = dkc_get_current_compiler()->source_encoding; > dkc_add_string_literal(yytext[0]); > if (enc == SHIFT_JIS_ENCODING > && ((unsigned char*)yytext)[0] >= 0x81 > && ((unsigned char*)yytext)[0] <= 0x9e) { > BEGIN SHIFT_JIS_2ND_CHAR; > } >} ><SHIFT_JIS_2ND_CHAR>. { > dkc_add_string_literal(yytext[0]); > BEGIN STRING_LITERAL_STATE; >} >

引用の順番を変えています。 >以下の箇所は、EUC版もWINDOWS版(SJIS)も違いがありませんが、 >コード系関係なく同じで構わないのでしょうか？ この部分は、 dkc_get_current_compiler()->source_encoding; の値により動きを変えており、それの値はMakefile中の -DSHIFT_JIS_CODEのような指定で制御しています(interface.c)。 しかし、仮にここの指定を誤っていたとしても、入力するソースがASCII文字からだけで構成されているのなら、エラーにはならないように思います。 >やっとDIKSAMが、マルチバイト無しの正常系が動作し始めました。 >まだ、マルチバイト無しのエラー系は完璧には動作していません。 「マルチバイト無しのエラー系」とのことですし。 >自分のSJIS環境では、「不正なマルチバイト文字です。」と >なってしまいます。 このエラーメッセージは、このように、列挙子BAD_MULTIBYTE_CHARACTER_ERRに対応しています。 dkc_compile_error(dkc_get_current_compiler()->current_line_number, BAD_MULTIBYTE_CHARACTER_ERR, MESSAGE_ARGUMENT_END); これが発生する箇所は、BAD_MULTIBYTE_CHARACTER_ERRで*.cを検索するとわかるようにDiksamのver.4系だと5箇所あるようです。 ver.2系だと4箇所のようです。こちら： http://kmaebashi.com/programmer/devlang/diksam_src_0_2/R/19.html その中のどれでエラーになっているかはわかりますでしょうか? 何を言っているのかというと、入力となるDiksamのソースのマルチバイト文字の解釈でエラーになっているのではなく、別の原因で起きたコンパイルエラーの、日本語エラーメッセージの変換でエラーになっているのでは? と思っているわけです。 そちらの環境が再現できてるわけでもないのであくまで推測です。また、もしエラーメッセージの変換で失敗しているのなら、「不正なマルチバイト文字です。」はなぜ正しく出るのかという疑問もわきます。 というわけで確定情報は出せませんが、参考になりましたら。

回答ありがとうございました。 凄く参考になりました。 GDBで確認しました、内容は以下の通りになります。 >その中のどれでエラーになっているかはわかりますでしょうか? string.c dkc_close_string_literal(void) { ････ ････ dkc_add_string_literal('\0'); new_str_len = dvm_mbstowcs_len(st_string_literal_buffer); if (new_str_len < 0) { ERRORメッセージ出力 不正なマルチバイトのエラーは、 dvm_mbstowcs_len() の復帰値が、”－１”で発生していました。 パラメタのst_string_literal_bufferは、”\240「,ヲィbb”で化けております。 入力ソースは1行だけで、　println("あいうえおbb"); マルチバイトなしでの確認をしました。 入力ソースは1行だけで、　println("aaaaaaaaa"); 正常に動作しました。 パラメタのst_string_literal_bufferは、「aaaaaaaaaa」でした。 なので、マルチバイトの時の読み込みがやはりうまくいっていないのだと 判断してもよいと思われます。 字句解析のどこで詰まっているんでしょうか？ GDBで解析してみましたが、イマイチ解析箇所がわかりませんでした。 また、なにかヒントがあれば教えてください。 ピンポイントで指摘して頂けるので、本当に助かります。 以上です、 よろしくお願い致します。

追加情報になります。 diksam.l の動作について SJIS対応の文字リテラルで関係のありそうな箇所（①～③）に、 printf()を入れてデバックしてみました。 ①～③までの役割は以下の解釈であっているでしょうか？ 　①は、マルチバイト処理用、 　　SJISコードの漢字の範囲のコードが来たら２バイト単位で 　　リテラルに取り上げる所 　②は、1バイト処理用 　　リテラル文字を１バイト単位でリテラルに取り上げる箇所 　③は、②の続きで、 　　コンパイル時の指定文字コードがSJISだった場合、 　　２バイト目に0x5cを持つ可能性がある1バイト目が来た場合、 　　次の2バイト目も一緒にリテラルに吸上げる所 ######### <STRING_LITERAL_STATE>[\x81-\x9f\xe0-\xef][\x40-\x7e\x80-\xfc] { ① dkc_add_string_literal(yytext[0]); dkc_add_string_literal(yytext[1]); } <STRING_LITERAL_STATE><<EOF>> { dkc_compile_error(dkc_get_current_compiler()->current_line_number, EOF_IN_STRING_LITERAL_ERR, MESSAGE_ARGUMENT_END); } <STRING_LITERAL_STATE>. { Encoding enc = dkc_get_current_compiler()->source_encoding; ② dkc_add_string_literal(yytext[0]); if (enc == SHIFT_JIS_ENCODING && ((unsigned char*)yytext)[0] >= 0x81 && ((unsigned char*)yytext)[0] <= 0x9e) { ③ BEGIN SHIFT_JIS_2ND_CHAR; } } ######### ”表”等の文字を入れても①③が表示されておらず、②ばかりでした。 自分の解釈からすると、日本語は①か③で処理されるはずだと 思っていましたが、どうも違っていました。 enc=SJISだと判定されていないのか？ SJIS文字コードは取得できていないのか？ どうしてそうなってしまうのか？ そこで、encの確認をしてみました。 ③のIFの条件を、SJISだった場合と2バイト目が0x5c範囲を持つものと段階的にバラシて見ました。 #### if(enc == SHIFT_JIS_ENCODING){ ④ if(((unsigned char*)yytext)[0] >= 0x81) && ((unsigned char*)yytext)[0] <= 0x9e) ){ ③ ##### ④は表示されました。コンパイルのencは問題ないようです。 ＠そこで、solaris特有なのか？と思い、 このサーバにEUCコードの環境を作って動作させて見ました。 ちょっと手を加える必要がありましたが、動作しました。 test/test.dkm を動作させた所、「不正なマルチバイト」が出力されました。 お尻の「日本語」の部分をコメントにしたら、正常に動作しました。 更に、「日本語」を分解していき、「語」があると「不正なマルチバイト」になる事がわかりました。 また、exit(1)を削除して、最後の文字列を表示させてみたら同じく「不正なマルチバイト」になり、上記と同様にしたら「れ」が原因だと判明しました。 語： B8EC れ： A4EC と2バイト目が"EC"で何かあるのでしょうか？0x5cの様なものが。 asciiコードの"EC"を見てもおかしくなるような感じはありませんでしたが・・・ 以上が現在の調査状況になります。 なにか、ヒントがあればよろしくお願い致します。 相手をしてくれて感謝しております。

>入力ソースは1行だけで、　println("あいうえおbb"); ええとですね。 >まだ、マルチバイト無しのエラー系は完璧には動作していません。 「マルチバイト無しのエラー系」が動かないのではなくて、「マルチバイトありの正常系」が動かない、というのが現状ということでしょうか? そうだとして、 >パラメタのst_string_literal_bufferは、”\240「,ヲィbb”で化けております。 >入力ソースは1行だけで、　println("あいうえおbb"); st_string_literal_bufferをデバッガで見たのだと思いますが、それだと、バイト列をデバッガが表示するところで文字化けが起きるので、渡ってきている正確なバイト列はわからないと思います。 ただ、いずれにしてもbbまで出ているわけですから、入力ファイルの、ダブルクォートが始まってから終わるまでの文字列は、dvm_mbstowcs_len()にまで届いているように見えま す。(たぶんですが。バイト数が違うっぽいのが結構怪しいですが) >①～③までの役割は以下の解釈であっているでしょうか？ >　①は、マルチバイト処理用、 >　　SJISコードの漢字の範囲のコードが来たら２バイト単位で >　　リテラルに取り上げる所 >　②は、1バイト処理用 >　　リテラル文字を１バイト単位でリテラルに取り上げる箇所 >　③は、②の続きで、 >　　コンパイル時の指定文字コードがSJISだった場合、 >　　２バイト目に0x5cを持つ可能性がある1バイト目が来た場合、 >　　次の2バイト目も一緒にリテラルに吸上げる所 これは合っていますけど、いずれにしてもこの処理は、「入力ファイルの、ダブルクォートが始まってから終わるまでのバイト列」を、間違いなくdvm_mbstowcs_len()に届けるための処理でしかありません。0x5cのような変な文字が来なければ、あまり意識しなくてよいはずのところです。 そこで確認ですが、 ①入力ファイルの文字コードは何でしょうか? od -cxかなにかでバイト列は取得できますか? ②dvm_mbstowcs_lenに渡す直前の、st_string_literal_bufferのバイト列は取得できますか? st_string_literal_buffer[0]～[12]までの値はわかりますか? そこまでわかったら、正確なバイト列がdvm_mbstowcs_len(の中のmbrtowc)に渡ったと仮定できますから、環境変数LANGが何であるのかとかの話になるのかと思います。

昨年はとてもお世話になりました、 今年もよろしくお願い致します。 連絡が、年を越してすみませんでした。 調査結果を報告します。 >そこで確認ですが、 >①入力ファイルの文字コードは何でしょうか? od -cxかなにかでバイト列は取得できますか? LANG=ja_JP.PCK のSJISです。 ソースのマルチバイトの部分のバイト列です。 println("あいうえおbb"); ^^^^^^^^^^^^^^ 22 82a0 82a2 82a4 82a6 82a8 62 62 22 でした。 >②dvm_mbstowcs_lenに渡す直前の、st_string_literal_bufferのバイト列は取得できますか? st_string_literal_buffer[0]～[12]までの値はわかりますか? > ・dkc_close_string_literal()の文字列長を得る関数の復帰値で、 「-1」が返って来た時に、バイト列を表示してみました。 ============================================== string.c:dkc_close_string_literal()　 L47: new_str_len = dvm_mbstowcs_len(st_string_literal_buffer); if (new_str_len < 0) { 追加> for(i=0;i<20;i++) 追加> printf("st_string_literal_buffer[%d]：%x \n", 　　　　　　　　i,st_string_literal_buffer[i]); ============================================== 結果： st_string_literal_buffer[0]：a0 st_string_literal_buffer[1]：a2 st_string_literal_buffer[2]：a4 st_string_literal_buffer[3]：a6 st_string_literal_buffer[4]：a8 st_string_literal_buffer[5]：62 st_string_literal_buffer[6]：62 st_string_literal_buffer[7]：0 st_string_literal_buffer[8]：0 ８バイト目以降は、0x00 になります。 マルチバイトの１バイトが飛ばされているようです。 ・文字列の取得についてですが、 　デバック用の文字列を入れて確認しました。 　-リテラル（ダブルクォーテーション）の最初と最後の取込みは出来ていました。 　-リテラル部分の取込みは、diksam.l Line295 で行われていました。 　　取込み時にもバイト列を表示させてみましたが、 　　上記と同じでした。 以上となります。 どうすれば、１バイト目が取り込めるようになるのでしょうか？ 現状のdiksam.l で不備はないと思えるのですが・・・ アドバイスをよろしくお願い致します。

>st_string_literal_buffer[0]：a0 >st_string_literal_buffer[1]：a2 >st_string_literal_buffer[2]：a4 >st_string_literal_buffer[3]：a6 >st_string_literal_buffer[4]：a8 >st_string_literal_buffer[5]：62 >st_string_literal_buffer[6]：62 >st_string_literal_buffer[7]：0 >st_string_literal_buffer[8]：0 >８バイト目以降は、0x00 になります。 > >マルチバイトの１バイトが飛ばされているようです。 確かにそのように見えますし、だとすると、原因はLANG環境変数とかではなく diksam.lということになりそうなのですが…… こちらで現象が再現していません。 >・文字列の取得についてですが、 >　デバック用の文字列を入れて確認しました。 >　-リテラル（ダブルクォーテーション）の最初と最後の取込みは出来ていました。 >　-リテラル部分の取込みは、diksam.l Line295 で行われていました。 お使いのdiksam.lの正確なバージョンは何でしょうか? (元の圧縮ファイルは どれをダウンロードされましたか?) diksam.lについては後半触っていないのでたぶん同じだと思うのですが、たとえば http://kmaebashi.com/programmer/devlang/book/download.html こちらのdiksam_book_0_4ですと、diksam.lの中にdkc_add_string_literal()の 呼び出しが何箇所かありますが、その中の Line285-286, Line295, Line303あたりの呼び出しについて、どのような順序で 呼び出されているかはわかりますでしょうか。それとも全部Line295でしょうか? こちらのデバッグにつきあわせてしまうことになるかもしれませんが、 よろしければご確認ください。 なお、失念していたのですが、diksam.lには以下の不具合があります。 http://kmaebashi.com/programmer/devlang/book/seigo.html#p186 この件には関係しないと思うのですが、追記しておきます。