K.Maebashi's BBS

>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()を信頼する」というスタンスですかね……