Link:

---

なるほど。。。
確かに自分で実装したTcpClientなら余計な補正は働きませんね。
動作確認できました。ありがとうございました。

Link:

---

最初からガッツリ調べなくても最初はfiddlerでいいんじゃない？appgoatの学習でも使っているツールだし。。。

Link:

---

ごぶさたしてます。

>なので、問題となった%E5,%9Eは、日本語をUnicode符合位置で求めた場合の
>下位1バイト分に相当します。

あ、気付いていませんでしたが確かにそうですね。
だとしても、なぜ「日本語」の場合だけそうなるのは謎ですが……

本件、Modoki/0.2はただソケットでデータを受け取るだけなので、
さすがにどっかで化けているとしたらブラウザだと思うのですが、
パケットフィルタリングもちょっと考えてみます。(今でもWiresharkで
よかったんだっけ…?)

Link:

---

>過去の例にあったような「http://localhost:8001/../conf/httpd.conf」
>をブラウザで入力してデバッグすると、NoSuchFileExceptionが先に発生するような
>動きをしてしまいました。

ブラウザは、こんなあからさまにディレクトリトラバーサルを起こしそうなURLを
素直にサーバに送らなければいけない義理もないでしょうから、

>「GET /conf/httpd.conf HTTP/1.1」となっていましたので、

というように(勝手に)変換しているのでしょう。

ただ、攻撃者はブラウザを使うとは限らないわけで、TcpClient.javaを使って
client_send.txtに

GET /../conf/httpd.conf HTTP/1.1

と書くと、

if (!realPath.startsWith(DOCUMENT_ROOT)) {

側の処理に流れ込むことが確認できます。

Link:

---

本を持っていないため、推測となってしまいますし、外しているかもしれませんが。。。
日本語のそれぞれの文字のUnicode符合位置は、[日]=U+65E5、[本]=U+672C、[語]=U+8A9Eです。
また、「,」は、Unicode符合位置がU+002Cです。
なので、問題となった%E5,%9Eは、日本語をUnicode符合位置で求めた場合の下位1バイト分に相当します。
この辺を手がかりに、パケットキャプチャすればどのタイミングまでは文字コードが意図通りとなっているかがのあたりがつくかもです。

Link:

---

こんばんは。

早々にご確認・ご回答頂きまして、まことにありがとうございます。
当方でも様々な文字で確認してみましたが、やはり上手くいくときといかないときがあり、よくわからない結果となってしまいました。
ブラウザ等の仕様に起因するところもあるかと思うので厳密には分からないかとは思いますが、もともとの目的である動き・仕様は理解できたので先に進もうかと思います。

ちなみに、また別の質問となってしまい恐縮ですが、
Modoki/0.2で、ディレクトリトラバーサル攻撃を検知 → 404.htmlをリターンする、
即ち (!realPath.startsWith(DOCUMENT_ROOT)) を true にするには、
どのようなGETリクエストを飛ばすと実現できるものでしょうか？

過去の例にあったような「http://localhost:8001/../conf/httpd.conf」
をブラウザで入力してデバッグすると、NoSuchFileExceptionが先に発生するような動きをしてしまいました。

TcpServerを動かして、ブラウザに「http://localhost:8001/../conf/httpd.conf」
を入力して、GETリクエストを取得してみると、
「GET /conf/httpd.conf HTTP/1.1」となっていましたので、
サーバがGETリクエストを受け取った時には、pathが/conf/httpd.confとなっているようです。
そうすると、realPathは「C:\Apache24\htdocs\conf\httpd.conf」になるので、
確かに、NoSuchFileExceptionが発生することが自然な動きのようにも思えます。

以上、よろしくお願いいたします。

Link:

---

はじめまして。ご質問いただきありがとうございます。

>入力URL　結果
>/test    OK（test配下のindex.htmlが表示）
>/test/　 OK（test配下のindex.htmlが表示）
>/日本語  NG（404.htmlも表示されずブラウザのエラー画面が表示）
>/日本語/ OK（日本語配下のindex.htmlが表示）

私も試してみましたが、正直、わけがわからない結果となっています。

Firefox, Edgeでは、

/日本語

の場合だけ、リクエストラインが以下のようになっています。

GET /%E5,%9E/ HTTP/1.1

これをデコードしても該当のフォルダは存在しないので、私が試した範囲では、
404が返りました。
IEでは、1回だけ

GET /%E6%97%A5%E6%9C%AC%E8%AA%9E HTTP/1.1

つまり正しくエンコードされた形でリクエストが投げられましたが、
以後何度試しても、そもそもリクエストが投げられず、ブラウザ側で
「このページを表示できません　
　Web アドレス http://localhost:8001  ;が正しいか確かめてください」
のエラーになっています。

奇妙なのは、Edge, Firefox, IEのどれにおいても、

http://localhost:8001/日本語/
http://localhost:8001/日本語.html
http://localhost:8001/あいうえお
http://localhost:8001/中国語

等はうまくいくのに、

http://localhost:8001/日本語

の場合だけ、

GET /%E5,%9E/ HTTP/1.1

になったり、リクエストが投げられなかったりしていることです。

SenderThread.javaの24行目に、以下のようにSystem.out.println()を挟んで確認しました。

  while ((line = Util.readLine(input)) != null) {
      if (line.equals(""))
          break;
      System.out.println("line.." + line);

Link:

---

はじめまして。
「Webサーバを作りながら学ぶ 基礎からのWebアプリケーション開発入門」にて実装したModoki/0.2の挙動について質問となります。

Modoki/0.2では、'/'なしでディレクトリを指定するとリダイレクトさせる仕様となっております。
そのため、「C:\Apache24\htdocs\」の配下にテストディレクトリ「test」と「日本語」を作成し、それぞれのディレクトリ配下にindex.htmlを配置して動かしてみました。

実行結果は以下の通りです。（入力URLはhttp://〜8001までは省略）

入力URL　結果
/test    OK（test配下のindex.htmlが表示）
/test/　 OK（test配下のindex.htmlが表示）
/日本語  NG（404.htmlも表示されずブラウザのエラー画面が表示）
/日本語/ OK（日本語配下のindex.htmlが表示）

ブラウザはIEでもFireFoxでも同じ結果でした。
デバッグモードで戻り値を確認してみましたが、MyURLDecoderは「/日本語」を返してくれていますし、realPathの取得時もNoSuchFileExceptionは発生していません。
このような差異が発生してしまう要因として考えられることはどのようなものでしょうか？

Link:

---

>webサーバを作ってみようページの以下リンクが切れております。

ありえないほど遅くなりましたが、ご指摘ありがとうございます。

とはいえよそのページなので消えるときは消えますし、それについて私にできることは
特にないよなー、と思ったのですが、Wayback Machineの存在を思い出したので
そちらに張りなおしておきました。

Link:

---

webサーバを作ってみようページの以下リンクが切れております。

http://ascii.asciimw.jp/books/support/4-7561-1663-9/supplement/0001/shttpd

Link:

---

>p.84のリスト3-3で、POSTのHTTPリクエストのサンプルを掲載していますが、
>ここでcheck_nameという同一のパラメタが複数回登場しています。
>つまり、チェックボックスを複数選択すると、この状況が発生します。
>p.85の脚注にも書いたとおり、この仕様は使いにくいとは私も思うのですが。
>
>
テスト掲示板だけでなく、前の入力フォームにも対応できるよう書かれていたのですね。
サーブレットコンテナを作っているのだから、こういう場合も想定しなければならないのに、
どうも頭が固かったみたいです。

お答えいただき、ありがとうございました。
また何かありましたら、よろしくお願いいたします。

Link:

---

>リスト3-17の21行目でif(paramterMap.containsKey(keyValue[0]))が
>trueになるケースはどんな場合でしょうか？本文P119の中頃に、『同一のパラメタが
>複数存在し得る』とあるのですが、このパラメタとはtittle, handle, messageのことですよね。
>１回のリクエストでこれらが複数になる場合というのがどうもよくわかりません。

p.84のリスト3-3で、POSTのHTTPリクエストのサンプルを掲載していますが、
ここでcheck_nameという同一のパラメタが複数回登場しています。
つまり、チェックボックスを複数選択すると、この状況が発生します。
p.85の脚注にも書いたとおり、この仕様は使いにくいとは私も思うのですが。

Link:

---

ご回答いただき、ありがとうございます。

>(試していませんが)param.split("=", -1) とすればよいかと思います。
>
試してみたところ、これでうまくいきました。

投稿内容の取得については、教えていただいた流れを追っていき、やっとわかりました。

stringToMapメソッドについて、まだ理解できていない点があるのですが、
リスト3-17の21行目でif(paramterMap.containsKey(keyValue[0]))が
trueになるケースはどんな場合でしょうか？本文P119の中頃に、『同一のパラメタが
複数存在し得る』とあるのですが、このパラメタとはtittle, handle, messageのことですよね。
１回のリクエストでこれらが複数になる場合というのがどうもよくわかりません。

教えていただければ幸いです。

Link:

---

はじめまして。

>Henacat起動まではうまくできたのですが、掲示板のタイトル・ハンドル名
>・メッセージの内のどこかが
>未入力のままで送信を押すと、リスト3-17のServletServiceの28行目で
>java.lang.ArrayIndexOutOfBoundsExceptionが発生します。
>keyValue[0]に対するkeyValue[1]がない、ということだと思うんですが、
>これはどこかコードを写し間違えているでしょうか？

このケースでは、ServletServiceの20行目の param.split("=") のところで、
split()メソッドの仕様上、「a=」という文字列をparam.split("=")のように
split()すると、
・戻り値の配列の要素数は2で、[0]には「a」が、[1]には空文字が入る
のではなく、
・戻り値の配列の要素数は1で、[0]にだけ「a」が入る
という仕様になっているためですね。
https://docs.oracle.com/javase/jp/6/api/java/lang/String.html#split(java.lang.String)

(試していませんが)param.split("=", -1) とすればよいかと思います。

Henacatはあくまでサンプル実装なので、こういうエラーケース的なものの
対処が甘いのはご容赦ください、と言いたいところですが、これはちょっと
実用上問題がありすぎるので、後ほど正誤表に上げさせていただきます。
ご指摘ありがとうございました。

>あと、このstringToMapメソッド内のparameterMapに過去の投稿内容も
>保持しているという認識で合っているでしょうか？
>しかし毎回メソッドが呼ばれるたびにnewしていては過去の内容は
>保持できませんよね？

parameterMapは毎回メソッドが呼ばれるたびにnewしていて、
1回のリクエストごとに使い捨てです。
リスト3-17 ServletService.javaの76行目で、

info.servlet.service(req, resp);

としてサーブレットのservice()メソッドを呼んでいますが、
この呼び出しが、リスト3-26のHttpServlet.javaの13行目のservice()メソッドを
呼び出すことになり、この中で、メソッドがPOSTの場合は(サブクラスの)doPost()
メソッドを呼んでいますから(19行目)、これはつまりリスト3-6のPostBBS.javaの
doPost()メソッドを呼び出しています。
ここで、新たにMessageクラスのインスタンスをnewして、staticフィールドの
messageListにメッセージをつないでいます。

Link:

---

Henacat起動まではうまくできたのですが、掲示板のタイトル・ハンドル名・メッセージの内のどこかが
未入力のままで送信を押すと、リスト3-17のServletServiceの28行目でjava.lang.ArrayIndexOutOfBoundsExceptionが発生します。
keyValue[0]に対するkeyValue[1]がない、ということだと思うんですが、これはどこかコードを写し間違えているでしょうか？

あと、このstringToMapメソッド内のparameterMapに過去の投稿内容も保持しているという認識で
合っているでしょうか？しかし毎回メソッドが呼ばれるたびにnewしていては過去の内容は保持できませんよね？

基本的なところかもしれませんが、どなたかわかる方、教えていただけますでしょうか。

Link:

---

>某社 F/W のレコードクラスは、Null値がセットされたメンバの値を get すると、
>長さ 0 の文字列を返す様にカスタマイズされています。その経緯は、過去の開発
>プロジェクトにおいて、ヌルポが氾濫していたのに対し、これを一気に黙らせる為
>の策が、そのまま生き残ったもの、と聞き及んでいます。

これは…… NullPointerExceptionは避けられるかもしれませんが、
アプリの要件として絶対に値を入れなければいけないところを空文字に
してしまったら、バグの発覚が遅れるだけですよね。
(この手のことは、拙著「センス・オブ・プログラミング!」で
「バグのあるプログラムには生きる価値はない」として書かせていただきました)
要件として、デフォルト空文字列でよいところは、コンストラクタ等で
空文字列で初期化するのは正しいと思いますが。

>「レコードクラスの100倍肥大化」は、多分、若者の早合点と思っており、若者には
>妙な言い訳をすることなく、真因を見極めるアプローチを怠って欲しくないと思い
>ます（デバッグ鍛錬）。

早合点なら、それでよいのですけれど。実際にメモリをバカ食いしている以上、
どこかに何かの原因があるのかとは思いますが。

>「Java謎＋落とし穴」から、Tiger となり、Java も随分進化したものと思いますが、
>貴殿がもし、同書の改定新版を上梓したとき、「謎＋落とし穴」は果たして減って
>いるのか増えているのかが、気になるところでございます、Hi。

JavaのGenericsはあれはあれで落とし穴が多いのですが、本1冊書くのは
それはそれは大変なので、当面おとなしくしていたいと思います。Hi。

Link:

---

前橋様

お返事有難うございます。まさかお返事を頂けると思っておりませんでしたので、
ホントに嬉しい限りです。実にショボイ当方の職場のドキュメンタリーは二の次、
先ずは、熱心な貴殿の１ファンの応援メールと受けって頂ければ幸いです。

某社 F/W のレコードクラスは、Null値がセットされたメンバの値を get すると、
長さ 0 の文字列を返す様にカスタマイズされています。その経緯は、過去の開発
プロジェクトにおいて、ヌルポが氾濫していたのに対し、これを一気に黙らせる為
の策が、そのまま生き残ったもの、と聞き及んでいます。

つまり嫌なのは Javaの言語使用なのではなく、このアホダラ F/W で育ったプログ
ラマーの資質の低下です。

穿った見方と思いますが、アセンブラや C言語で鍛えられたプログラマーは、設計、
仕様、要件をやらしても、モレや矛盾といったバグを仕込むことが少ないと思いま
す。

「ユーザーをバカにするシステムは、良いシステム」という、妙な格言紛いよろし
く、「プログラマーをバカにするプログラミング言語は、良い言語」では困りモノ
です。考えなくて良くなる分、その代わりに、高品質、短納期、斬新なアイデアを
O/P して欲しいものです。

「レコードクラスの100倍肥大化」は、多分、若者の早合点と思っており、若者には
妙な言い訳をすることなく、真因を見極めるアプローチを怠って欲しくないと思い
ます（デバッグ鍛錬）。

「Java謎＋落とし穴」から、Tiger となり、Java も随分進化したものと思いますが、
貴殿がもし、同書の改定新版を上梓したとき、「謎＋落とし穴」は果たして減って
いるのか増えているのかが、気になるところでございます、Hi。

Link:

---

はじめまして。すっかり閑古鳥な掲示板ですが、投稿ありがとうございます。

>貴殿の「Java謎＋落とし穴」は私の愛読書で、もう、10年以上も手許に置き、
>休日の午後など、思い出しては手に取って、ニヤニヤしている時間が好き
>です。もう少し余裕ができたら、「 プログラミング言語を作る」を読み込
>んでみたいと思ってます（プログラミング工学の楽しい部分なのですが、
>私にはチとハードルが高い）。

ありがとうございます。「Java謎＋落とし穴」は、さすがに今となっては
内容が古いのですが、Tiger以前の本としては良く書けた本であったと
自分でも自賛しております。

>このクラスのコンバート元である、いわゆるC言語の関数では、いわゆる
>構造体のリストで、その構造体のサイズは80バイト、100万件でも 80MB、
>これにリスト形成に必要なオーバーヘッドを加えても、たかが知れてます。

100倍以上となると単に言語の違いとするには差が大きすぎますし、
Cだと1回のmalloc()で済むものがJavaだといくつものオブジェクトに
なってしまうというのもありがちですが(たとえばCなら構造体に
intの配列を埋め込んでいたところ、JavaだとArrayList<Integer>を
使ったりすると、あっさり100倍くらいにはなりそうな気がします)、
『某社標準の「フレームワーク」』が問題なのでしょうか。
ものを見ていないので何も言えませんけれども。

>これに対する、若者の回答が問題なのだ。
>　　若者「Null Pointer Exceptionが怖くて、それはできません。」

NullPointerExceptionはバグがあるから起きるので、それ自体を避けたからといって
問題の解決にはなりませんよね(『某社標準の「フレームワーク」』を使うと、
どうNullPointerExceptionを避けられるのかはわかりませんが)。

>「メモリ馬鹿ばか食い」はともかく、「プログラマーの資質（≒誇り）」
>まで低下させる、嫌な言語だ、Java は。

とはいえ、それをJavaという言語のせいにするのもちょっと(Javaに対して)酷なような気が……

Link:

---

貴殿の「Java謎＋落とし穴」は私の愛読書で、もう、10年以上も手許に置き、
休日の午後など、思い出しては手に取って、ニヤニヤしている時間が好き
です。もう少し余裕ができたら、「 プログラミング言語を作る」を読み込
んでみたいと思ってます（プログラミング工学の楽しい部分なのですが、
私にはチとハードルが高い）。

私は、Lattice C からの「C言語使い」です。K&Rにも随分お世話になりま
した。現在、愛知県某社の某基幹システムのリニューアルで、これまで
C言語で実装されていた UNIXサーバーの巨大システムを、Javaにコンバー
トする仕事をしております。

仕事と言いましても、もはや定年までカウントダウンの身、第一線から引
き、「相談役」みたいな立場で食い繋がせて頂いております。

Javaプログラマとしての経験は浅いことを申し添えておきます。

昨日、若者から以下の様な相談をされました。

　　大量データ検証で、あるクラスのアウトプットが、List<データ型>
　　(ArrayList) で、100万件、消費メモリサイズが 10GB で、これでは
　　同時並行稼働すると、後続プロセスの JVMが起動することができなく
　　なる恐れがあります。

該当のサーバーは、今や当たり前の仮想モノで、JVM専用のヒープサイズ
として約30GB割り当てられているのですが、これでは、多分2平行でも、
OutOfMemory となってしまうでしょう。何せ、解析ツールによると、
処理中に GC発生しまくりで、いわばメモリ確保とGCの追っかけっこ、
GCが追い付かない時の最大使用メモリが 20GBに達する、とのこと。

このクラスのコンバート元である、いわゆるC言語の関数では、いわゆる
構造体のリストで、その構造体のサイズは80バイト、100万件でも 80MB、
これにリスト形成に必要なオーバーヘッドを加えても、たかが知れてます。

このアウトプットの 10GB と 80MB の差という視点に絞ってサクッと考え
ると、Java 側の <データ型> が、bean よりもさらに保安性、利便性？で
ガチガチに固められた、某社標準の「フレームワーク」準拠のスーパーク
ラスをスーパークラスに、このシステムオリジナルの利便性をプラスした
もので、純粋なデータ部分のオーバーヘッドが酷いものと思われる。

これに対し、私は一言、「<データ型>を、せめて bean にしなさい。」と
伝えた。

これに対する、若者の回答が問題なのだ。

　　若者「Null Pointer Exceptionが怖くて、それはできません。」

　　私「…。」

「メモリ馬鹿ばか食い」はともかく、「プログラマーの資質（≒誇り）」
まで低下させる、嫌な言語だ、Java は。

　「プログラマーの資質（≒誇り）」も、C言語と Java とは違う所に
ある様なんですね。

Link:

---

ふぉげちゅうーてゃ？
ｆｏｒｇｅｔ　ｙｏｕ！が語源かも。

Link:

---

>P.280図8-4で、start_x,y,end_x,y,center_x,yと書いているのに、
>P.281図8-5や、P.282図8-6で、start..x,y,end..x,y,center..x,yと、書き変えて？いる。

ご指摘ありがとうございます。遅ればせながら確認しました。
確かに、アンダースコアであるべきところが「..」になっています。
執筆当時のオリジナル原稿を確認しましたがアンダースコアになっていたので
(そりゃ間違えるにしてもこんな間違え方はしないでしょうし)、
書籍用に作図された方にうまく意図が通じなかった&私の確認不足、ということかと
思います。
後日、正誤表に載せさせていただきます。ありがとうございました。

Link:

---

理解度はどうあれ、世間でいうGWが終わったので私も読了です。今後しばらくはこの書籍についてはコメント（というか愚痴）はしません。お付き合いいただき、ありがとうございました。
とりあえず、ほとんどどうでもいいことですが、正誤表に上がっていないので１つ。
P.280図8-4で、start_x,y,end_x,y,center_x,yと書いているのに、
P.281図8-5や、P.282図8-6で、start..x,y,end..x,y,center..x,yと、書き変えて？いる。

それでは。

Link:

---

自己解決しました。 

client_send.txtの最後の空行がエディタAtomによって勝手に削除されていたことが原因でした。 
お騒がせしました。

Link:

---

はじめまして。

現在「Webサーバを作りながら学ぶ 基礎からのWebアプリケーション開発入門」を勉強中です。

p.54ページのTcpClient.javaを使って存在しないファイルをリクエストするという部分で
404が返ってこず、408のタイムアウトが返ってきてしまいます。

存在するファイルをリクエストしても408が返ってきてしまいます。

これより前は全てうまくいっていたのですが、このタイムアウトはどのような原因が考えられるのでしょうか。

サーバはDocker上でApacheを使用しています。ブラウザだと想定どおりの動きです。

自分で解決することができず、投稿させて頂きました。
よろしくお願いいたします。

Link:

---

回答ありがとうございます。（1か月ぐらいした後に消そうと思っていて、正直回答を期待していなかったので少し驚きました。）

>>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;
>
>

うーん、コード読んでないのがバレました。（だって人が書いた長いコードをインタビューなしで読むのはしんどいもの。。。）で、nextの音の響きから、左から右、上から下、低層から高層（深層）の方向と想定してました。
だから、「最新のLocalEnvironmentのみから検索しますが、nextをたどって、呼び出し経路すべてのLocalEnvironmentから検索するようにすると、」の記述を、
「「最新のLocalEnvironmentのみから検索しますが、【トップレベルでの（グローバル変数に格納された）LocalEnviromnent型の変数を参照の後】nextをたどって、呼び出し経路すべてのLocalEnvironmentから検索するようにすると、」
と補って読んでいました。
なので、nextの本来の使い道はガベージ判定で、ダイナミックスコープ判定の用途でも使えることを言っているのかな？と類推していました。

ま、この部分の私の理解は大体間違っていましたね。

とりあえず、私の理解不足を棚上げしておいて、別の意味に捉えかねないnextの名前が悪い、っと愚痴っときます。（えぇ暴論ですとも。）

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

Link:

---

ゴールデンウィークで読み終えられるかなと思っていたけど全然そうじゃなかった。
やっと、5章まで読み終わった。で、いろいろ愚痴りたい。（今回は投稿にパスワードをつけたので消す準備はバッチリです。）

まずは、環境依存の問題
今週末は一人で0x0d問題にぶち当たり全然読み進められなかった。
test.crbを食わせても以下のメッセージしか出ない。
5:(0x0d)@ 
win_sjisのtest.crbだと、改行にCR(0x0d),LF(0x0a)が入れられていて、
今使っている処理系（Microsoft Windows Subsystem for Linux上のubuntu）
では、0x0dを無視してくれず、改行コード\n(=0x0a)に到達する前に不正な文字で引っかかっている、がubuntuのターミナルは、SJISを解釈してくれず文字化けを起こす。結局が悪いのかがわからない。
今の時代趣味でやる分にはsjisもeucも地雷じゃないかなあ？

で、読む気力がそがれたので、重箱の隅を突っ込みながら（またしても）表面をなぞる程度の読み込みになっちゃった。ちゃんと読めるのはいつのことになるんだか。。。

で、突っ込みはこんな感じ。
電卓の場合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（専用のというか普通）の型のローカル変数を使わないのかな？
とか、

p.141の網掛けの以下の記述
　a={1,2,3};
  a={2,3,4};
のあとの図で、aから出ている矢印が{4,5,6}を指している。
{4,5,6}というのはどこから出てて来た？というか{2,3,4}はどこいった？
とか、

p.145のビットフィールド。別にCのプロフェッショナルを目指す本ではないので、ビットフィールドなんて説明が必要な機能なんて使わずにしれっとCRB_Boolean使ったり、そのままズバリintを使えばいいじゃない。
とか、

p.153のダイナミックスコープの説明でnextから辿る場合、
仮に自身と呼び出し元に同じ変数名を定義し、自身内で変数を参照する場合、先に呼び出し元の変数が検知されてしまうので、ダイナミックスコープの動きと違うのでは？
とか、

p.178
mbstate_をmemset()等でゼロクリアというmbstate_ってどこから出てきた？

って感じです。あと、5章UNICODEについては、組み文字以外にデータ内に入っている（文字送り方向や字形の変更など）
制御コードをどう扱っているのかも書いてあればななあとも思いました。この辺って、例えば１文字のはずなのにデータは100byteとか作れそうで、セキュリティホールになりやすい感じがするので、なぜ問題にならないかを聞きたかったかも。

Link:

---

なるほど、わかりました。回答ありがとうございました。
P.39は、正規表現の話だけかと思って（読み返した時に何度も何度も）読み飛ばしていました。この箇所の記述にlexの動きについて書かれていたのですね。失礼しました。
私が誤解していたのは、最初に現れたトークン定義にマッチした場合に、以降のトークン定義を無視するんだろうなぁと思っていたことです。
なので、P.39に記述について+と++のトークンについては、lexの記述では当然に最初に++の定義があってその後に+の定義があるものと思い込んでいました。実際には+と++はマッチする長さが違うのだからlexの記述では、どちらを先に定義しても動きは変わらないのですね。

Link:

---

>疑問に思ったのは「123.456」を「123」を整数型トークン、「.」を例外トークン、
>「456」の整数型トークンと判断する方法や、「1」,「2」「3」「.」「4」「5」「6」を
>全て例外トークンとして扱うこともできそうな気がするのですが、そうならない
>理由がわからないためです。

これは、lexがなぜ「123.456」を実数トークンとして解釈するのかがわからない、
ということでしょうか?
lexは、「最長一致」でトークンを切り出します。つまり「123」や「1」よりも
「123.456」のほうが長いので、「123.456」は実数トークンとして解釈されます。
それについては本の中ではp.39の一番下の段落で説明しています。

>また、整数トークンと実数トークン、"if"トークンと[ \t]トークンの関係から
>推測すると、例えば"for while other if"みたいな命令語もトークンとして
>定義できそうですが、その場合に.lファイルでの定義行（ルール順番）によっては
>動きが変わるものなのでしょうか？

同じところに書いてある通り、lexはまず「最長一致」でトークンを切り出そうとし、
長さが同じなら、より前の規則、つまり.lファイルでの定義行が上のほうである
規則を優先します。

>整数型の場合「....|"0"」と0をダブルクォーテーションで括っていますが、
>電卓のケースでP.36では、「(....|0|([0-9]....)」と0をダブルクォーテーションで
>括っていません。この違いが上の判断条件に影響しているのでしょうか？

これはどちらでも同じですね。なぜ片方だけダブルクォートで囲んだのかは、
すみませんがさすがに思い出せません……