K.Maebashi's BBS

util.cについて教えてください。 /* BUGBUG CRB_NativeFunctionProc * 　　　　. 　　　　. */ とコメントにしたのはなぜでしょうか。 /*FALLTHRU*/というのは何かの指令なのですか。 C ソースコード検査プログラムの lint と関係ありますか。

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

こちらは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は何だったのか、 よければ教えてもらえませんか。

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

>crowbar_book_0_1に、debubgフォルダとmemoryフォルダがあったのですが >これらは何のためのフォルダなのですか。 「高校生」さんが書籍版「プログラミング言語を作る」をお持ちなら、 92ページにディレクトリ構成の図があります。メモリ管理モジュール MEM(memoryフォルダ)の説明はp.92からありますし、デバッグ用モジュール DBG(debugフォルダ)の説明はp.96からです。 Web版なら、以下のページに説明があります。 http://kmaebashi.com/programmer/devlang/crowbar_0_1.html こちらにはdebugのほうの説明はないので補足すると、たとえば 以下のソースが例として挙げられると思います。 http://kmaebashi.com/programmer/devlang/crowbar_src_0_1_01/S/22.html#57 >if (cond.type != CRB_BOOLEAN_VALUE) { > crb_runtime_error(statement->u.if_s.condition->line_number, > NOT_BOOLEAN_TYPE_ERR, MESSAGE_ARGUMENT_END); >} >DBG_assert(cond.type == CRB_BOOLEAN_VALUE, ("cond.type..%d", cond.type)); このDBG_assert()を通るときにはcond.typeは絶対にCRB_BOOLEAN_VALUEであるに 決まっているわけですが、万一なにかの思い違いでそうでなかったとき、 DBG_assert()はメッセージを2行吐いて異常終了します。

crowbar_book_0_1に、debubgフォルダとmemoryフォルダがあったのですが これらは何のためのフォルダなのですか。 一通り見たのですが難しいです。 こんな質問ですみません、学校のレポートにまとめなければならないので...。

>２．UTF-8版の場合 >次のようなメッセージを２回表示しアボートします。 > >Assertion Failure (WC_format != NULL) file .. error.c line .. 92 当方のUbuntu Linuxで再確認しましたが、正常動作しました。 確認ですが、この時のLANG環境変数の値は何になっているでしょうか? Linuxなら、LANG環境変数の値は「echo $LANG」で確認することができます。

Windows XP上のVirtualPCでVine Linuxを起動し、EUC版とUTF-8版のDIKSAM_book_0_4を実行してみました。 どちらもWindowsの時のようにdiksam.yのソース修正することなくmakeは正常に終了しました。 TEST.DKMを引数にして実行すると次のような差異が生じました。 １．EUC版の場合 実行結果はTESTディレクトリ内のTEST.RESULTと同じ内容が表示されます。 正常終了!! ２．UTF-8版の場合 次のようなメッセージを２回表示しアボートします。 Assertion Failure (WC_format != NULL) file .. error.c line .. 92 アボートしました。 *** とりあえず　Linuxでは EUC　コードで先に進めていきます。 *** 誰かＩｎｔｅｌ　Ｍａｃでの実行を試行してみませんか !!! 以上

>CrowbarからCを使うとありましたが,Cで書かれた別アプリケーションからインタプリタを使うことについて、どういうことかイメージがわきません。 「crowbarからCの関数を呼び出すことの意味はわかるけれど、 　Cからcrowbarのインタプリタを呼び出せて何が嬉しいのかわからない」 ということでよいでしょうか? Cで書かれたある程度の規模のプログラムがあるとして、そこからcrowbarが 呼び出せると、crowbarを、そのプログラムのカスタマイズ用言語として使うことが できます。 すぐ思いつく例としては、 ・Microsoft WordやExcelはカスタマイズ用言語としてVBAを使うことができる。 ・UNIXのエディタEmacsは、Emacs Lispでカスタマイズできる。 ・CADなどでは、カスタマイズ用スクリプト言語がついているものがある。 などがありますが…考えてみれば高校生はOfficeは使わない気がするし、 UNIXも使っていなければEmacsも知らないかもしれないし、ましてやCADを 見たことがあるとも思えませんねえ。 手近な例としては、秀丸エディタのマクロなんかどうでしょうか。 http://hide.maruo.co.jp/lib/macro/index.html

CrowbarからCを使うとありましたが,Cで書かれた別アプリケーションからインタプリタを使うことについて、どういうことかイメージがわきません。説明やいいサイトを紹介してくれたら幸いです。

>出力結果と文字コード表を付き合わせると、Shift-JISじゃなくてEUCだと思うのですが……。 出力結果： > str[0]..50940 16進数に直すとC6FC 文字コード表を見ると…すみません、確かにEUCでした。ご指摘ありがとうございます。 同じ手順で確認したはずが、なぜShift-JISだと思ってしまったんだろう。 >つよしさんのテストではワイド文字への変換は行われているがUnicode化されていない。 >青餓鬼さんのテストではそもそもワイド文字にも変換されず、素のバイト列のまま、と。 ということですよね。つよしさんの実験がEUC環境下で行われたなら、実質無変換で、 ただしマルチバイトの1文字として変換されたということでしょうか。

Mac持ってませんが探究中です。 >なぜか当時追及しなかったようなのですが、Windowsと同じようには動いていませんね。 >この出力だけ見ると、ワイド文字に変換した結果がShift-JISになっているように >見えますが、いくらなんでもそんなはずは…… 出力結果と文字コード表を付き合わせると、Shift-JISじゃなくてEUCだと思うのですが……。 つよしさんのテストではワイド文字への変換は行われているがUnicode化されていない。 青餓鬼さんのテストではそもそもワイド文字にも変換されず、素のバイト列のまま、と。 引き続き調査しまーす。

>crowbar.hを見ていると/*create.c*/や/*string.c*/などが書いてありました。 これですね。 http://kmaebashi.com/programmer/devlang/crowbar_src_0_4_02/S/6.html >これは、例えばcreate.cというファイルが、crowbar.hの/*create.c*/と書いてある以下の部分を使うということですか。 「以下の部分を使う」というのをどういう意味で書かれているのかはわかりませんが、 このコメントは、 「/* create.c */というコメントの下にある関数は、create.c内で定義されている」 ということを意味しています。

crowbar.hを見ていると/*create.c*/や/*string.c*/などが書いてありました。 これは、例えばcreate.cというファイルが、crowbar.hの/*create.c*/と書いてある以下の部分を使うということですか。 気になりまして。

>私が問題にしているのは、Test.dkmの726行目 > if (str[i] == '本') { >の解釈で、WindowのCYGWINのGCCが作成した実行部は２バイト文字として >文字リテラルを解釈しているのに、MacのGCCで作成した実行部は文字リテラル数が >複数あるとしてエラーとしていることです。 まず、Diksamでは、"あいうえお".length()は5を返しますし、"あいうえお"[3]の 値は'え'である、というのが仕様です。つまり、Diksamでは、文字列は「バイトの 並び」ではなく「文字の並び」です。この「文字」は、日本語であっても、 1文字は1文字として解釈されなければなりません。 よって、実行に成功していれば、test.dkmにおける以下のコードの実行結果は、 string str = "日本語"; for (i = 0; i < str.length(); i++) { println("str[" + i + "].." + str[i]); if (str[i] == '本') { println("本"); } } 以下のようになるのが正解です。 str[0]..26085 str[1]..26412 本 str[2]..35486 ところが、青餓鬼さんの環境では、str.length()がEUCではが6, UTF-8では9に なっています。これはマルチバイト文字からUNICODEへの変換が行われておらず、 単にバイト列として読み込まれているように見えます。 マルチバイト文字からUNICODEへの変換処理はロケールに依存するので、 環境変数LANGの値はどうなっているのかが気になっているわけです。 とはいえ私はMacは持っておりませんしOS-Xを使ったこともないので、 見当はずれのことを書いている可能性はあります。詳しい方ご指摘ください。 過去MacOSで動かした人はいたはずだったよな、と思い掲示板の過去ログを 探したところ、以下の投稿が見つかりました。 http://kmaebashi.com/bbs/list.php?boardid=kmaebashibbs&from=1196&range=1 なぜか当時追及しなかったようなのですが、Windowsと同じようには動いていませんね。 この出力だけ見ると、ワイド文字に変換した結果がShift-JISになっているように 見えますが、いくらなんでもそんなはずは……

私が問題にしているのは、Test.dkmの726行目 if (str[i] == '本') { の解釈で、WindowのCYGWINのGCCが作成した実行部は２バイト文字として文字リテラルを解釈しているのに、MacのGCCで作成した実行部は文字リテラル数が複数あるとしてエラーとしていることです。 文字リテラルに関しては、ほかの手段を執るか制限を設けるのか検討が必要だと思います。 以上

>lexicalanalyzer.cを見ていると >#if 0 >と書かれていましたが、どういう意味でしょうか。 #で始まっていることから、#includeと同じようなプリプロセッサの機能であると 見当がつきます。 そこで、「プリプロセッサ」でGoogle検索すると、たとえば以下のようなページが 見つかります。 http://www.cppll.jp/cppreference/preproc_details.html >/*ここから下はテストドライバ*/ >とありました。これはなくてもよいのですか。 >何を意味しているのかを教えてください。 「テストドライバ」でGoogle検索するとWikipediaの以下のページが見つかります。 http://ja.wikipedia.org/wiki/%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E3%83%86%E3%82%B9%E3%83%88#.E3.83.86.E3.82.B9.E3.83.88.E3.83.89.E3.83.A9.E3.82.A4.E3.83.90.E3.81.A8.E3.83.86.E3.82.B9.E3.83.88.E3.82.B9.E3.82.BF.E3.83.96

scanf()の件はありがとうございました。 lexicalanalyzer.cを見ていると #if 0 と書かれていましたが、どういう意味でしょうか。 本のほうでは、 /*ここから下はテストドライバ*/ とありました。これはなくてもよいのですか。 何を意味しているのかを教えてください。

すみません、時間がないので手短に。 >◎◎結論 >文字列型stringの内部の表現形式は実行環境のＣ言語コンパイラに依存するとなると、他のＵｎｉｘ／Ｌｉｎｕｘは >わかりませんが、Ｍａｃ／Ｗｉｎでの日本語のリテラル処理は、同じソースでは扱えないと思います。 内部の表現形式以前に、test.dkmの文字コードがunix_euc.tarではEUC、 unix_utf8.tarではUTF8になっており、それがそのまま出力されているように 見えます。 echo $LANG とすると、何が表示されますか?

Diksam_book_0_4について、ＷｉｎとＭａｃの実行結果を次に示します。 ★Ｗｉｎｄｏｗｓの場合（ＸＰ　ソースファイルはwin_sjis.lzh） 正誤表にあるCompilerディレクトリのdiksam.yのblockに関するソース修正を行い、diksam.yの７４５行目のソースを catch_clause : CATCH { $$ = dkc_start_catch_clause(); } 次のように修正すると catch_clause : CATCH { $<catch_clause>$ = dkc_start_catch_clause(); } ｍａｋｅは正常に終了し、test.dkmを処理してもtest.resultと同じ結果が得られます。 ★Ｍａｃ（PPC Ｇ５，ＯＳ　１０．４．１１ ソースファイルはunix_euc.tar） diksam.yのソース修正をしなくてもmakeは正常に終了しますが、test.dkmを処理しようとすると 726行目のところでエラーとなります。（たぶんエラー内容は下と同じ） そこで次のようにソース修正すると、 string str = "日本語"; for (i = 0; i < str.length(); i++) { println("str[" + i + "].." + str[i]); // if (str[i] == '本') { if (i>0 && str[i-1] == 203 && str[i] == 220) { println("本"); } } 次のような結果が表示されます。 ・・(前の部分省略) 日本語 str[0]..198 str[1]..252 str[2]..203 str[3]..220 本 str[4]..184 str[5]..236 ★Ｍａｃ（PPC Ｇ５，ＯＳ　１０．４．１１ ソースファイルはunix_etf8.tar） diksam.yのソース修正をしなくてもmakeは正常に終了しますが、test.dkmを処理しようとすると 726行目のところで"文字リテラルが２文字以上あります"というエラーとなります。 そこで次のようにソース修正すると、 string str = "日本語"; for (i = 0; i < str.length(); i++) { println("str[" + i + "].." + str[i]); // if (str[i] == '本') { if (i>2 && str[i-2] == 230 && str[i-1] == 156) && str[i] == 172) { println("本"); } } 次のような結果が表示されます。ただし、結果をファイルに落としてＷｉｎで表示させると日本語の部分は文字化けします。 ・・(前の部分省略) 日本語 str[0]..230 str[1]..151 str[2]..165 str[3]..230 str[4]..156 str[5]..172 本 str[6]..232 str[7]..170 str[8]..158 ◎◎結論 文字列型stringの内部の表現形式は実行環境のＣ言語コンパイラに依存するとなると、他のＵｎｉｘ／Ｌｉｎｕｘは わかりませんが、Ｍａｃ／Ｗｉｎでの日本語のリテラル処理は、同じソースでは扱えないと思います。 以上、Ｍａｃ／Ｗｉｎの実行結果を報告します。

>crowbarにはC言語で言うscanf(キーボードから入力）的なものは、ありましたでしょうか。 少なくとも最新バージョン(book_ver.0.4)では、fgets()の入力元を STDINにすることでキーボードからの入力が可能です。 str = fgets(STDIN); print(str); Cのscanf()のように、文字列を数値に変換するような機能はありませんので、 必要であればネイティブメソッドを書き足してみてください。

電卓の件は、ありがとうございました。 crowbarにはC言語で言うscanf(キーボードから入力）的なものは、ありましたでしょうか。

>mycalc|_exで例えば >..5 >とか入力すると >電卓は終了してしまうのですか。 >それともlexical error とかが出るのですか。 現状では、手書きパーサのほうは syntax error. yacc/lex版のほうは、 lexical error. と表示して終了します。 yacc/lex版の_exありのほうは、パーサのエラーについては対処しており、 たとえば 1++2 のように入力すれば、エラーメッセージを出しますが電卓は終了しません。 確かにレキシカルアナライザの方でエラーが出ると終了してしまうので 実用上は対策がおおいに不完全ですが、ここではyaccのエラー処理の仕方を 説明しているということでご理解ください。 …とはいえ補足記事くらいは書いたほうがよさそうですね。検討します。

mycalc|_exで例えば ..5 とか入力すると 電卓は終了してしまうのですか。 それともlexical error とかが出るのですか。

>win_sjisのcalcフォルダにある電卓にはエラー処理はありますか？ 本のほうで説明しているのはyaccのエラー処理の方法なので、 calcフォルダ以下の、mycalc_ex以下のmycalc.yにはエラー処理が入っています。 _exでないほうには入っていません。

>情報ありがとうございました。正直、Makefileの中身を書き換える根性はないのですが、 >補足等の形で近日中にUPさせていただきます。 修羅場だったり出張してたりでここに書くのが遅くなりましたが、 申しわけ程度の説明を↓のページに入れました。 http://kmaebashi.com/programmer/devlang/book/winenv.html 今見返しても本当に申しわけ程度ですが……

win_sjisのcalcフォルダにある電卓にはエラー処理はありますか？

……とは言っても、Makefileにコマンドを書いた時点で、そもそもシェル依存なのか。 cdの構文が（ある程度）共通してるのはラッキーだったというだけで。 すいません、ひとりで納得してますm(_ _)m

まず、訂正。 >cd ../dvm; $(MAKE)$ 末尾の$は不要でした。 >makeが起動しようとするコマンド行を受け付けるのが、Cmd.exeの場合に >セミコロンを解釈しない、ということでしょうか。 そういうことだろうと思います。 >正直、Makefileの中身を書き換える根性はないのですが、 パスをダブルクォーテーションで囲んでみたり、 なんとかcmd.exeの機嫌をとろうとしたのですが、 うまく行く方法が見つかりません(^^;) 蛇足ですが、cdと$(MAKE)を別行にしてしまうと、 新しいシェルが立ち上がって、cd前のディレクトリに戻ってしまい、 makeで自分と同じMakefileを読みに行って再帰無限地獄に陥いりますよね。 #ってか、MinGWユーザが全員MSYS入れてるわけでもないでしょうし、 #けっこう普遍的な問題のような気がするのですが、情報が見つかりません。

>> cd ../dvm; gmake; >> 指定されたパスが見つかりません。 >> gmake: *** [../dvm/dvm.o] Error 1 > >といったエラーに悩んでる人が出てきてないでしょうか。 > >MSYSだと起こらないので、今日初めて気づいたんですが、 Cygwinを入れている私の環境でもそのままでは再現しませんが、 makeが起動しようとするコマンド行を受け付けるのが、Cmd.exeの場合に セミコロンを解釈しない、ということでしょうか。実際、コマンドプロンプトから 直接入力すると、同様のエラーが出ます。 情報ありがとうございました。正直、Makefileの中身を書き換える根性はないのですが、 補足等の形で近日中にUPさせていただきます。