K.Maebashi's BBS 投稿フォーム

ハンドル名
件名
Link

>>win_sjisのtest.crbだと、改行にCR(0x0d),LF(0x0a)が入れられていて、
>>今使っている処理系（Microsoft Windows Subsystem for Linux上のubuntu）
>>では、0x0dを無視してくれず、改行コード\n(=0x0a)に到達する前に不正な文字で
>>引っかかっている、
>
>なるほど、crowbar.lでは「\n」だけを改行扱いにしていますから、
>UNIX環境下では0x0dは不正な文字として扱われますね。
>もともと、Windows(かつてはDOS)にてCでテキストファイルを扱う際、
>改行を\r\nとして扱わなければならないのでは既存のUNIXベースの
>ソースが軒並み壊滅するので、Windows/DOS環境下では、fopen()とか
>fgetc()とかの標準入出力ライブラリのレベルで、\r\nを\nに変換するという
>対策を取っています(バイナリファイルを扱いたいときにはfopen()に
>"r"の代わりに"rb"を渡す)。「Microsoft Windows Subsystem for Linux上のubuntu」
>ではこの動きにならないのは、WindowsではなくLinuxであるためでしょう。
>
>>今の時代趣味でやる分にはsjisもeucも地雷じゃないかなあ？
>
>まあそのあたりは、2009年の本ですので(その当時でもちと古かったのかも
>しれませんが)。
>
>>電卓の場合yyparse()で無限ループしているのに、crowbarではyyparse()以降の
>>処理に進んでいることは誰も疑問に思わないのかな、
>
>電卓では入力が終わりませんからね。
>
>>p.121 2個目のelse if文の中の処理、
>>　left_val.u.double_value=left_val.u.int_value;
>>  eval_binary_double(...)
>
>
>>の部分で、left_val.typeは変えずに(INTのまま)格納する共用体にはdouble値を入れている。
>>その後left_valはそのまま使わず、left_val.u.double_valueのみ使っているので
>>問題にはならいけど、読んでて不安になる。なぜdouble（専用のというか普通）の
>>型のローカル変数を使わないのかな？
>
>ちょっと当時の意図は思い出せませんが、左辺をdoubleに型変換した
>感じを出したかったのかもしれません。確かに今見ると、ちょっと意図の
>よくわからないコードになっているとは思います。
>
>>p.141の網掛けの以下の記述
>>　a={1,2,3};
>>  a={2,3,4};
>>のあとの図で、aから出ている矢印が{4,5,6}を指している。
>>{4,5,6}というのはどこから出てて来た？というか{2,3,4}はどこいった？
>>とか、
>
>p.146ですね。誤植のようです。正誤表に載せておきます。
>ご指摘ありがとうございました。
>
>>p.145のビットフィールド。別にCのプロフェッショナルを目指す本ではないので、
>>ビットフィールドなんて説明が必要な機能なんて使わずにしれっとCRB_Boolean
>>使ったり、そのままズバリintを使えばいいじゃない。
>
>これにはたぶん段階のようなものがあって、
>(1)unsigned long flagsみたいは変数にフラグを押し込んで、
>　自力でビット演算
>(2)ビットフィールド
>(3)しれっとなんでもCRB_Boolean
>当時、実用に供されているCのコードだと、(1)が多かったと思います(ひょっとすると
>今でも)。それに比べれば進歩(?)だと思っておいてください。
>(本にも「まあ、富豪的プログラミングの感覚からすれば、1ビットのフラグでも、
>CRB_Boolean型ひとつ割り当てるべきなのかもしれませんけど。」と書いていますが)
>
>>p.153のダイナミックスコープの説明でnextから辿る場合、
>>仮に自身と呼び出し元に同じ変数名を定義し、自身内で変数を参照する場合、
>>先に呼び出し元の変数が検知されてしまうので、ダイナミックスコープの動きと
>>違うのでは？
>
>最新のLocalEnvironmentを起点にnextをたどって変数を検索すると、
>先に検知されるのは呼び出し元ではなく自身の方なのでは……?
>一応ver.0.2のeval.cのalloc_local_environmentを確認しましたが、
>新LocalEnvironmentのnextに、その時点でのトップのLocalEnvironmentを
>連結していますし。
>
>635: ret->next = inter->top_environment;
>636: inter->top_environment = ret;
>
>
>>p.178
>>mbstate_をmemset()等でゼロクリアというmbstate_ってどこから出てきた？
>
>文脈からすると「mbstate_t」の誤りのようです。正誤表に載せておきます。
>
>
>>って感じです。あと、5章UNICODEについては、組み文字以外にデータ内に入っている
>>（文字送り方向や字形の変更など）制御コードをどう扱っているのかも書いてあれば
>>ななあとも思いました。この辺って、例えば１文字のはずなのにデータは
>>100byteとか作れそうで、セキュリティホールになりやすい感じがするので、
>>なぜ問題にならないかを聞きたかったかも。
>
>この本のプログラムでは、「mbrtowc()を信頼する」というスタンスですかね……
>

spamよけのため、ここに「ほげぴよ」と入力してください。

削除パスワード : クリック！