K.Maebashi's BBS

C言語において、文字定数は1バイトの表現に収まることが保証されていますが、 たとえば'A'が200のような値をとっていけないことはないですよね。 すると、charがsignedな処理系で char hoge = 'A'; と書くと、未定義動作になるのでしょうか？

fd

test

ｃｖｇｃｇｄｇｈｄｇおっぱ

ああああなんあなん

tinkoとmankoを合体させよう

おppai

どうもはなくそです

鼻隠せ

河野、がやべぇ鼻の中ほじくりまはわしてる

ｍんこのー　　おしりのなかを　　なまないでくださいー

鼻の整形をひきうけましょうか？

ぱぱぱぱぱぴい

河野逃げるな

鼻くそ見えてるよ

鼻デカ

ま　こ

鼻でか

洋一郎が怒られるのこわいからにげた

まえののー　　おしりのなかを　　なめないでくださいー そこに

鼻でか

どうすんの？

あああ

千の風になっての替え歌を作りたいんだが。

>仕様について簡単に説明します。 > >・発言内容は全て<pre>で囲まれます。ソースリストを載せるのに便利にするためです。 >　適当な位置で改行を入れてください。 >・でもやっぱり改行を入れ忘れる人もいるので、プレビュー表示をつけました。 >　確認してから「送信」をクリックしてください。 >・タグは全無効です。<font color="red">ほらね</font> >・クリッカブルURLの機能があります。 >　http://kmaebashi.com >　タグは無効なので<a>タグは書けません。 >・現状では削除機能がないので削除用パスワードは単なるお飾りです。 >・スレッド表示時、スレッドトップの「▼」をクリックすると、そのスレッドの >　発言を一覧表示します。 >・一画面あたりの表示数は以下の通りです。 >　- 日付順表示…30 >　- 日付順インデックス…50 >　- スレッド表示…20スレッド >

>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 この件には関係しないと思うのですが、追記しておきます。

昨年はとてもお世話になりました、 今年もよろしくお願い致します。 連絡が、年を越してすみませんでした。 調査結果を報告します。 >そこで確認ですが、 >①入力ファイルの文字コードは何でしょうか? 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 で不備はないと思えるのですが・・・ アドバイスをよろしくお願い致します。

>入力ソースは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が何であるのかとかの話になるのかと思います。

追加情報になります。 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"を見てもおかしくなるような感じはありませんでしたが・・・ 以上が現在の調査状況になります。 なにか、ヒントがあればよろしくお願い致します。 相手をしてくれて感謝しております。