[2129] Re:いろいろ愚痴りたい（（プログラミング言語を作る3章～5章 ）
投稿者：(ぱ)こと管理人
2018/05/02 16:46:30
>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()を信頼する」というスタンスですかね……