K.Maebashi's BBS

鼻デカ

ま　こ

鼻でか

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

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

鼻でか

どうすんの？

あああ

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

>仕様について簡単に説明します。 > >・発言内容は全て<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"を見てもおかしくなるような感じはありませんでしたが・・・ 以上が現在の調査状況になります。 なにか、ヒントがあればよろしくお願い致します。 相手をしてくれて感謝しております。

回答ありがとうございました。 凄く参考になりました。 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で解析してみましたが、イマイチ解析箇所がわかりませんでした。 また、なにかヒントがあれば教えてください。 ピンポイントで指摘して頂けるので、本当に助かります。 以上です、 よろしくお願い致します。

引用の順番を変えています。 >以下の箇所は、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のソースのマルチバイト文字の解釈でエラーになっているのではなく、別の原因で起きたコンパイルエラーの、日本語エラーメッセージの変換でエラーになっているのでは? と思っているわけです。 そちらの環境が再現できてるわけでもないのであくまで推測です。また、もしエラーメッセージの変換で失敗しているのなら、「不正なマルチバイト文字です。」はなぜ正しく出るのかという疑問もわきます。 というわけで確定情報は出せませんが、参考になりましたら。

すみません、回答遅れております。 その場所は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; >} >

先日は、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; }

素早い回答ありがとうございます。 連絡が遅れてすいませんでした。 >(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で詳しく調べていきます。 わからない事があったら、またお願い致します。 ありがとうございました。

>高校生活最後の昼休みには何をすればよいか？ 高校生は卒業前は学校は半ドンになったりして、高校生活最後の昼休みって 結構早い時期にあったりしてたっけか。 まあ、とりあえず、メシを食えばよいのでは。

はじめまして。 >なので、漢字コードが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版のソースを参考にされるとよいのではないかと。

初めて投稿します。 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.

高校生活最後の昼休みには何をすればよいか？

再度ありがとうございます。 ># 集合論的におかしい 激しく同意。例によって例のごとく、といいますか(^^;) >となり、やはり int となるため問題ないです。 了解です。 >6.7.2.2 の[制約]は[定数の値を定義する式]としか書いてないので、 >enum e_bbb { bbb=2147483647, ccc }; は言語規格書的には合法と考えざるを得ません。 ># gcc ではきっちりコンパイルエラーになりますが。 ですよねぇ。そこも凄く気になってました。 ちなみにLSI-Cで試すとコンパイルが通りました。 （intが2バイトで、bbbを32767とするとcccは-32768）

以下 JIS X3010:2003 より抜粋するので C の場合に限定 6.7.2.2 - 列挙型 - 列挙子並びの中の識別子は、型 int を持つ定数として宣言され、 この型の定数が許されるところならばどこに現れてもよい なので元ネタのキャストは要らないと判断してよさそうです。 enum e_aaa 型の underlying type は char であってもよい、のと、 その要素である aaa の型は int である、のとが矛盾してるように見えますが・・・ # 集合論的におかしい enum 型の識別子ではなくて enum 型の変数（オブジェクト）が現れた場合には 6.2.5 - 型 - 列挙体は[整数型]である 6.3.1.1 - 整数型 - 整数拡張 元の型のすべての値が int 型で表現可能な場合 int 型に変換される 6.7.2.2 - 列挙型 - 列挙定数の (既述につき snip) となり、やはり int となるため問題ないです。 6.7.2.2 の[制約]は[定数の値を定義する式]としか書いてないので、 enum e_bbb { bbb=2147483647, ccc }; は言語規格書的には合法と考えざるを得ません。 # gcc ではきっちりコンパイルエラーになりますが。 C++ の場合はこの辺いろいろ規制緩和されている＋言語仕様も厳密化されているので 仕様書を読んでいて安心できます。先の [制約] のような不安要素も文書化され済み。

774RRさん、ありがとうございます。よく理解できました。 列挙体のメンバを右辺値として使うときに「int型の定数」とみなして実質的に不都合が起こることはなさそうですね。

>例えばメンバの値の範囲がcharで収まるなら、 >処理系はcharを使って領域を節約してもよい ですます。たとえば gcc であれば -fshort-enums オプションがあります。 enum e_aaa { aaa=1 }; printf("%zd\n", sizeof (enum e_aaa)); -fshort-enums なしでコンパイルすると 4 -fshort-enums ありでコンパイルすると 1 >あくまで「（charと適合する）列挙型の列挙定数」であって、 >式の中に現れると汎整数拡張されてint型に格上げされる ですます。 ただし sizeof('a') と同様に C と C++ で違うところなので要注意。 printf("%zd\n", sizeof (aaa)); gcc -fshort-enums hoge.c だと 4 g++ -fshort-enums hoge.cpp だと 1

C限定の話で、列挙型についての疑問です。 JIS X3010:2003の6.7.2.2 列挙型指定子(p77～p78)に、 > 制約　列挙定数の値を定義する式は、int型で表現可能な値を持つ整数定数式でなければならない （中略） >それぞれの列挙型は、char、符号付き整数型又は符号無し整数型と適合する型とする。型の選択は、処理系定義とする。しかし、その型は列挙型のすべてのメンバの値を表現できなければならない。 とあります。 列挙型が必ずしもint型ではなく上記のような選択の余地を処理系に与えているのは、 例えばメンバの値の範囲がcharで収まるなら、処理系はcharを使って領域を節約してもよい、という意義だと理解してよいのでしょうか？ 通常、列挙体のメンバを式中で用いるときには、何も意識せずにint型の定数として （私は）書いているのですが、このメンバ自体はint型とは限らないわけですよね。 ある列挙型に対して例えば「charと適合する型」が選ばれた場合、そのメンバは あくまで「（charと適合する）列挙型の列挙定数」であって、 式の中に現れると汎整数拡張されてint型に格上げされる、という理解でよいのでしょうか？ この疑問が生じた直接のきっかけは、（ぱ）さんの「プログラミング言語MIL」の雑誌記事のmini_mvm.cにおいて、 (A)や(B)の箇所でintへのキャストがなされているのを見て、「どんなときにキャストすべきなんだっけ？」と再考したことによります。 相変わらず記事の本筋と関係なくてすみません……。 皆様よろしければご教示ください。 typedef enum { OP_PUSH_INT, OP_ADD, OP_MUL, OP_PRINT } OpCode; int g_bytecode[] = { /* (A) */ (int)OP_PUSH_INT, 10, (int)OP_PUSH_INT, 2, (int)OP_PUSH_INT, 4, (int)OP_MUL, (int)OP_ADD, (int)OP_PRINT, }; int st_stack[STACK_SIZE_MAX]; void mvm_execute(void){ int pc = 0; int sp = 0; // スタックポインタ while (pc < sizeof(g_bytecode) / sizeof(*g_bytecode)) { switch (g_bytecode[pc]) { case OP_PUSH_INT: // 整数をスタックに積む st_stack[sp] = (int)g_bytecode[pc+1]; /* (B) */ sp++; pc += 2; break; case OP_ADD: // 加算 /* 以下略 */ } } }

また、モチベーションが落ちてきた… 根性が居る修正を始めようとして、なぜか横道に逸て、逸れすぎて。 何をしようとしてたか忘れた。 もちろん、大きな内容の修正は忘れてないが、ソースのどの部分を修正しようと してたのか忘れた… 何かしないと復活できない＞＜ （日記ですね；；）