K.Maebashi's BBS

>51行目 >誤：<thead> >正：</thead> ご指摘ありがとうございます。ポカが多く申し訳ありません。 正誤表に追加しました。

『基礎からのWebアプリケーション開発入門』のP.219にあるリスト6-11について、非常にささいではありますが誤植かなと思ったところがあったので、念の為、連絡しておきます。 51行目 誤：<thead> 正：</thead>

>P.199 >6.5節の認証はクライアント側の認証、6.4.1節②の認証はサーバ側の認証の話、 >という理解で合っていますでしょうか？ まあそうですが、クライアント側、サーバ側というと意味が不明確かと。 ・6.5節の認証は、ログインしているユーザが正しいユーザであることを 　確認するための認証 ・6.4.1節②の認証は、通信相手のサーバが正しいサーバであることを 　確認するための認証 です。 >P.204 >レルムはパスワードファイル作成時（htdigest）にも指定し、「.htaccess」にも >指定しています。これらの整合性は、どのように扱われるのでしょうか？ 同じものを2か所に書いているから整合性が心配だということだと思いますが、 p.204に「これはつまり、複数のレルムのユーザを、1つのパスワードファイルで 管理できることを意味しています」とあるように、レルムをキーに どの領域のユーザかを識別しているわけです(いかにも表示用の文字列を キーにするのが気持ち悪いというのは同意します)。 >P.205 >ncは何をカウントしているのでしょうか？同じノンスに対するレスポンスの >送信回数が2回以上という状況が想像できませんでした。 リプレイ攻撃の防止用です。通信経路が盗聴されている時、正当な利用者が 投げた認証情報とまったく同じ情報を攻撃者が投げると認証が通ってしまう、 という事態を防止するためのものです。 >P.208 >「フォーム認証では～SSL（TLS）を使用しなければ～」とありますが、 >tomcatのフォーム認証は暗号化されているのでしょうか？それとも別途、 >暗号化が必要なものなのでしょうか？ リスト6-5のlogin.htmlを見ればわかるようにただのform要素なので、 暗号化はされません。別途TLSを使用する必要があります。 >P.211 >④の後のShowBBSを表示するリクエストとレスポンスで、JSESSIONIDの値が違いました。 >これは、なぜでしょうか？セッションIDの固定化(Session Fixation)攻撃と >関係あるのでしょうか。 関係あります。このページの説明がわかりやすいかと思います。 http://bakera.jp/glossary/%E3%82%BB%E3%83%83%E3%82%B7%E3%83%A7%E3%83%B3%E5%9B%BA%E5%AE%9A%E6%94%BB%E6%92%83

『基礎からのWebアプリケーション開発入門』のP.199からの認証について何点か質問させてください。 P.199 6.5節の認証はクライアント側の認証、6.4.1節②の認証はサーバ側の認証の話、という理解で合っていますでしょうか？ P.204 レルムはパスワードファイル作成時（htdigest）にも指定し、「.htaccess」にも指定しています。これらの整合性は、どのように扱われるのでしょうか？ P.205 ncは何をカウントしているのでしょうか？同じノンスに対するレスポンスの送信回数が2回以上という状況が想像できませんでした。 P.208 「フォーム認証では～SSL（TLS）を使用しなければ～」とありますが、tomcatのフォーム認証は暗号化されているのでしょうか？それとも別途、暗号化が必要なものなのでしょうか？ P.211 ④の後のShowBBSを表示するリクエストとレスポンスで、JSESSIONIDの値が違いました。これは、なぜでしょうか？セッションIDの固定化(Session Fixation)攻撃と関係あるのでしょうか。

>①Webサーバがたくさんある場合 >「アプリケーションサーバソフトウェア（Tomcatなど）が再起動した場合には、 >セッションが失われてしまいます」とありますが、それはなぜでしょうか？ >アプリケーションサーバソフトウェアを再起動すると、その上で動くサーブレットも >再起動となりセッションもクリアされるからでしょうか。その意味では、 >Webサーバがたくさんある場合とは直接関係ないものでしょうか？ 確かに、Webサーバが1台でも「Webサーバが壊れたとか、アプリケーションサーバ ソフトウェア（Tomcatなど）が再起動した場合には、セッションが失われてしま」う ことに変わりはないですね。 意図としては、Webサーバがたくさんある場合、普通は「1台くらい壊れても 問題なく動作する」ことを期待して「冗長化」するのであって、にもかかわらず (そのサーバに接続していたユーザだけとはいえ)セッションが失われてしまうのでは Webサーバをたくさんにした意味がない、という趣旨で書いています。 >②セッションをCookie以外で実現する方法 >「URL Writing」の説明に「RefererなどでセッションIDが漏洩しやすい」とありますが、 >それはなぜでしょうか？CookieならばJavascriptから見えないようにすることが >できるからでしょうか？ CookieならJavaScriptから見えないようにできるというのもありますが、 この文章での意図としては、書いてある通り「RefererなどでセッションIDが漏洩」すると いうことです。SNSなどで、悪意を持ったユーザが自サーバのURLを貼ったら、 そのサーバのアクセスログのRefererのところに、うっかりリンクを踏んだ人の セッションIDが普通に現れます。

『基礎からのWebアプリケーション開発入門』のP.163、164の補足について質問させてください。 ①Webサーバがたくさんある場合 「アプリケーションサーバソフトウェア（Tomcatなど）が再起動した場合には、セッションが失われてしまいます」とありますが、それはなぜでしょうか？ アプリケーションサーバソフトウェアを再起動すると、その上で動くサーブレットも再起動となりセッションもクリアされるからでしょうか。その意味では、Webサーバがたくさんある場合とは直接関係ないものでしょうか？ ②セッションをCookie以外で実現する方法 「URL Writing」の説明に「RefererなどでセッションIDが漏洩しやすい」とありますが、それはなぜでしょうか？CookieならばJavascriptから見えないようにすることができるからでしょうか？

>というわけで、プログラム出力は兎も角として、解説の文章では(第2版でも仰っている >ように)必要な冠詞を抜かさず英語としてまともな文章になさるほうが良いと、僕は >思います。 本来の英語としてはそうだろうと思います(intの前とかは微妙な気もしますが)。 本書内のは、まあ、説明用の英語もどきということでご理解ください。

>># あ、本の中の英語の文章ですが、可算名詞に冠詞が抜けているものが少なからず >>ありました… > >これはK&Rのdclもそうなっているからいいだろう、ということで付けていません。 >第2版では、p.163に注の形で言い訳を入れました。 >(韓国語版では、訳者の方が足してくれたりしたようですが) ># この注で、「declでも付けていませんし」とあるのはdclの間違いですね… ># 後ほど正誤表に挙げます。 あ、本当だ！ この件に関しては、第2版を確認せずに投稿しちゃってました… (^^; 確かに、K&$第二版日本語版のp149の、dcl『の実行結果』も、冠詞が抜けています。 原著第二版(1988)のp122ページの『実行出力』でも、ありませんね。 また、"Pointers on C" (Kenneth A. Reek, Addison Wesley(1988))のp355で 紹介されている、cdeclというプログラム https://cdecl.org/ https://github.com/ridiculousfish/cdecl-blocks 『の出力』でも、冠詞は省略しているみたいですね。 $ cdecl Type `help' or `?' for help cdecl> explain int(*f)(void); declare f as pointer to function (void) returning int しかし、これは、あくまでプログラム出力を簡潔にするためだと思います。 実際、"C - A Reference Manual (5ed.)"(Harbison & Steel, Prentice Hall (2002))の 4 Declarationsという章の最初のページ(p73)にも Declarations in C are difficult to describe for several reasons. First, they involve some unusual syntax that may be confusing to the novice. For example, the declaration int (*f) (volid); declares a pointer to a function taking no arguments and returning an integer. と、文章ではきちんと冠詞をつけていることからも、英語としては冠詞が必要である ことが明らかですし、K&R原著第二版で配列が最初に説明される 1.6 Arrays (p22)で でだって、本文文章では The declaration int ndigit[10]; declares ndigit to be an array of 10 integers. と書かれています。 というわけで、プログラム出力は兎も角として、解説の文章では(第2版でも仰っている ように)必要な冠詞を抜かさず英語としてまともな文章になさるほうが良いと、僕は 思います。

>結局、Cの宣言は、日本語的に考えるとダメで(識別子から遠い側の配列宣言[3]を先に解釈 >しないと正しくない)、英語で表現して考えないとダメだ、ということなんでしょうかね… そうです。 まあ、Cの宣言は英語圏でも「酷評を受ける」そうですが、 日本人にとってはさらにひとつハードルが増えますね。 ># あ、本の中の英語の文章ですが、可算名詞に冠詞が抜けているものが少なからず >ありました… これはK&Rのdclもそうなっているからいいだろう、ということで付けていません。 第2版では、p.163に注の形で言い訳を入れました。 (韓国語版では、訳者の方が足してくれたりしたようですが) # この注で、「declでも付けていませんし」とあるのはdclの間違いですね… # 後ほど正誤表に挙げます。

>コンパイラが密かに(いえ、きちんと被参照型のサイズを考えて)計算して正しい >値(アドレス)に置き換えてくれてる、ということなのですかね(でしょうね)? そういうことですね。

バカな質問ばかりして恐縮です。 第1版のp144に『②識別子に近い方から、優先順位に従って派生型(ポインタ、配列、関数)を解釈する。』とあります。 これでいくと、Table 3-1の3番目、 int hoge[10][3]; は、 　「識別子"hoge"に一番近いのは、配列[10]。その次が配列[3]。最後に、int」 なので、 　「要素数10個の配列が、3つ並んで(また配列を作って)いる。(基本型はint)」 となると思えるのですが、“日本語的表現”では 　hoge は、intの配列(要素数3) の配列(要素数10) と、「要素数3の配列が10個並んでいる」という意味とされています。(Fig. 3-15でも同様) 結局、Cの宣言は、日本語的に考えるとダメで(識別子から遠い側の配列宣言[3]を先に解釈しないと正しくない)、英語で表現して考えないとダメだ、ということなんでしょうかね… (質問というか、ぼやき?) "'hoge' is an array (with 10 elements) of an array (with 3 elements) of int." # あ、本の中の英語の文章ですが、可算名詞に冠詞が抜けているものが少なからずありました…

>>この時、ip はポインタ(型の変数)ですよね?　ですから、ip+2、すなわち、 >>ポインタ(型の変数の値)に2加算したポインタ『値』は、あくまで2しか増えて >>いないじゃない!、と僕は思ったわけです。 > >うーん、『「ポインタ型の値」は、実際にはメモリのアドレスのことです』と >p.43には書いてあるわけで、その意味では一貫していると思うのですが…… > >ip+1としたとき、それはもちろん配列の添字として考えれば1しか増えてないですし、 >引き算すれば1になりますが、図を描いて矢印が動く距離を見てみれば、 >「そのポインタが指す型のサイズ分だけ」動いている、と思うのですが。 僕の混乱の原因は、ここにありまして… List 1-4array2.c を、ちょっとだけ変更した次のもの #include <stdio.h> int main(void) { int array[5]; int *p; int *p0=&array[0], *p1=&array[1]; int i; /* 配列arrayに値を設定 */ for (i = 0; i < 5; i++) { array[i] = i; } /* その内容を表示 */ for (p = &array[0]; p != &array[5]; p++) { printf("%d %p\n", *p, p); } printf("p1-p0: %d, %p\n", p1-p0, p1-p0); return 0; } を走らせた結果は 0 0x7ffc25766960 1 0x7ffc25766964 2 0x7ffc25766968 3 0x7ffc2576696c 4 0x7ffc25766970 p1-p0: 1, 0x1 となり、『pには1しか足していないのに(p+=1としても当然同じ)、それを表示 させるとなぜ4ずつ増えている?　どこにマジックがある?』という当惑です。 (1足した筈なのに、4増えちゃった?　でも、p1とp0の差は、あくまで、1!) コンパイラが密かに(いえ、きちんと被参照型のサイズを考えて)計算して正しい 値(アドレス)に置き換えてくれてる、ということなのですかね(でしょうね)?

>この時、ip はポインタ(型の変数)ですよね?　ですから、ip+2、すなわち、 >ポインタ(型の変数の値)に2加算したポインタ『値』は、あくまで2しか増えて >いないじゃない!、と僕は思ったわけです。 うーん、『「ポインタ型の値」は、実際にはメモリのアドレスのことです』と p.43には書いてあるわけで、その意味では一貫していると思うのですが…… ip+1としたとき、それはもちろん配列の添字として考えれば1しか増えてないですし、 引き算すれば1になりますが、図を描いて矢印が動く距離を見てみれば、 「そのポインタが指す型のサイズ分だけ」動いている、と思うのですが。 >…というわけで、『ポインタ「の指し示すアドレス」が〇〇だけ進む』などという 『ポインタ「の指し示すアドレス」』だと、ポインタの指す先にあるアドレスが 増えるという意味にとられそうな気もしますけど、 まあ、「ポインタが〇〇だけ進む」と書くよりは、「ポインタが〇〇バイトだけ進む」と 単位を明示した方が、誤解を招かなかったかもしれませんね。

>しかし、自然に考えると「WebAppCollection」クラスを分離して、「WebAppCollection」が >「WebApplication」のコレクションを保有する構造の方が分かりやすいのではないか、と >思ってしまいました。 この構造は、確かにわかりやすくてこれでもよいと思いますが、 >そこで、現在の「WebApplication」の構造にした背景みたいなものがあれば、 >聞いてみたいと思ったわけです。 現状こうなっているのは、「すべてのWebApplicaionのインスタンスが、 必ずwebAppCollectionに格納されていることを保証する」ためです。 コンストラクタがprivateにしてあるので、WebApplicationのインスタンスは WebApplication.createInstance()を呼ぶ以外に生成の方法がなく、 必ずwebAppCollectionに格納されていることが保証されます。

『基礎からのWebアプリケーション開発入門』のP.114のリスト3-15にある「WebApplication」クラスについて、少し疑問があります。 書籍の本論とはズレた疑問ですが。。 「WebApplication」は自分自身のコレクション「WebAppCollection」を内部に持っています。 しかし、自然に考えると「WebAppCollection」クラスを分離して、「WebAppCollection」が「WebApplication」のコレクションを保有する構造の方が分かりやすいのではないか、と思ってしまいました。 （「Main」は「WebAppCollection」に「addWebApplication」を依頼する、みたいな） そこで、現在の「WebApplication」の構造にした背景みたいなものがあれば、聞いてみたいと思ったわけです。 このようなことを聞く理由は、次のような感じです。 書籍でHenacatを勉強していて、いろいろなクラスが登場し、それぞれの関係性を理解して、という作業を行ったのですが、なかなか難しいという感想を持ちました。 そう感じる理由はクラス間の関連（全体感）をつかめないからで、もしかするとUMLとかで整理したら分かりやすくなるのかな？と思って試してみました。 しかし、なかなか上手く表現できず「WebApplication」の構造が気になり始めた、という事が理由です。 いつもご迷惑をおかけしますが、よろしくお願いいたします！

>>2-3-2ポインタ型派生で(第1版p151、第2版p172)、「くどいようですが繰り返して >>おきます。ポインタに対して加算を行うと、そのポインタの指す型のサイズだけ、 >>ポインタが進むのでした。」とありますが、ポインタの指す型のサイズだけ進むのは、 >>(通常のポインタの実装では)【アドレス】であって、ポインタが進む大きさは、 >>ポインタに加算した量だけ、ではないでしょうか? > >この「ポインタが〇〇だけ進む」という表現は、第2版p.56の > >>ポインタって、要するにアドレスのことなんだろ？ >>だったら、1足したら1進むに決まってるじゃないか！ > >のところから一貫して「バイト数」を指しているつもりです。 (略) >そして、こういう説明が必要だと思ったからこそ、私はこの本を書いたわけです。 有難うございます。感謝しながら読ませて頂いております。 混乱してきました。あ、勿論、ポインタの指す先がどれだけ進むか?は、理解しているつもりです。 int i, iarray[10]; int *ip; ip = iarray で int が 4bytes である場合に、 *(ip+2); が、iarray の先頭アドレスから 4*2=8bytes を参照していることはわかっているつもりです。 この時、ip はポインタ(型の変数)ですよね?　ですから、ip+2、すなわち、ポインタ(型の変数の値)に2加算したポインタ『値』は、あくまで2しか増えていないじゃない!、と僕は思ったわけです。そして、「ポインタが〇〇だけ進む」という表現は、『ポインタ「の値」が〇〇だけ進む』と読めました。その指す先は、勿論、8bytes 進んだ場所ですが… (ipとip+2の差はあくまで2ですが、ip+2がdereferenceする先とipがdereferenceする先の番地の差は、2*sizeof(int)、で、バイト数で考えて意味をもつのは、あくまでdereferenceする先では?) …というわけで、『ポインタ「の指し示すアドレス」が〇〇だけ進む』などという表現の方が、くどい文章になるけれど、誤解する僕のようなバカチンは減るのでは?と申したわけです。 細かくてすみません…

>>ついでに申せば、第1版のFig.3-3の「1加算するとここを指す」という説明も、 >>よくわかりません。どういう意味でしょうか？何に1加算すると？ > >この図中にある「Tへのポインタ」に1加算すると、です。 あ、配列へのポインタの説明のFig.3-6と見比べて、わかりました。 これ、あるオブジェクトがぽつんとある図ではなく、メモリ空間内で図の上から下にアドレスが大きくなっていっていて、「Tへのポインタ」が「派生元の型T」のとある変数?の場所の手前を指していて、「Tへのポインタ」に「1加算するとここ(「派生元の型T」のとある変数?の場所の次)を指す」、という意味なのですね！ 理解しました。

返信ありがとうございます。 endianについては、VAX/VMSやらPC98やらをいじっているその昔から(トシがばれる(^^;)苦労させられてきていて、中身はわかっているつもりですので、「何と逆なのか」を明示して頂ければ、僕はそれだけで充分です。(僕が細かすぎですかね?(笑)) >>第1版p135, 第2版p156の、byteorder.cの実行直後の文、『私の環境では「0x12345678」と >>いう値は、メモリ上に、逆向きに配置されているようですね。』とあるのですが、 >>何とは「逆向き」に、なのかがわかりません。何と逆向きなのでしょうか? > >「0x12345678」という16進の表記と逆向き、という意味で書いています。 (略) >「想定読者は過去の自分自身」という視点から逃れられないものなのかもしれません。 繰り返しになりますが、「何と逆か」が明確に示していただければ、「あぁ、それと逆なのね」と、読者の一人としては納得できます。「下位から上位に読んでいったら、全然逆じゃないじゃん！何と逆?　うぅーん、わからん！」と考える、ひねくれた読者もおりますので(笑)

>ついでに申せば、第1版のFig.3-3の「1加算するとここを指す」という説明も、 >よくわかりません。どういう意味でしょうか？何に1加算すると？ この図中にある「Tへのポインタ」に1加算すると、です。

>2-3-2ポインタ型派生で(第1版p151、第2版p172)、「くどいようですが繰り返して >おきます。ポインタに対して加算を行うと、そのポインタの指す型のサイズだけ、 >ポインタが進むのでした。」とありますが、ポインタの指す型のサイズだけ進むのは、 >(通常のポインタの実装では)【アドレス】であって、ポインタが進む大きさは、 >ポインタに加算した量だけ、ではないでしょうか? この「ポインタが〇〇だけ進む」という表現は、第2版p.56の >ポインタって、要するにアドレスのことなんだろ？ >だったら、1足したら1進むに決まってるじゃないか！ のところから一貫して「バイト数」を指しているつもりです。 私だって普通にポインタ演算(まあめったに使いませんが)でintの配列の 次の要素を指す時には、「4バイト先」なんてことを意識したりはしませんが、 この本では、「そのポインタの指す型のサイズだけ、ポインタが進む」ということを 強く意識しないと、たとえばp.195の 「ポインタにi加算することは、そのポインタが指す型のサイズ×iだけ、 ポインタを進めることを意味する。hogeの指す先の型は「intの配列（要 素数5）」であるから、hoge + iでは、sizeof(int[5]) * iだけ進む。」 という説明が意味不明になってしまうのではないでしょうか。 そして、こういう説明が必要だと思ったからこそ、私はこの本を書いたわけです。

>第1版p135, 第2版p156の、byteorder.cの実行直後の文、『私の環境では「0x12345678」と >いう値は、メモリ上に、逆向きに配置されているようですね。』とあるのですが、 >何とは「逆向き」に、なのかがわかりません。何と逆向きなのでしょうか? 「0x12345678」という16進の表記と逆向き、という意味で書いています。 >(ぱ)さんの環境(little endian)で、78->56->34->12と表示されている、 >というのは、下の位から上の位にメモリアドレスが増えていっているので、 >僕には、逆ではなく【順に】に思えるのです。 うーん、主観の問題とは思いますが、どうなんでしょう。 「下の位を先にメモリに格納する」というのは、コンピュータの事情としては わかるケースもありますが、通常、人間は、数字を印刷・表示した状態の順序で 意識しているのではないでしょうか。過去、この話を新人君やお客様にしたことは 何度かありますが、私の経験した範囲では、「へー、逆なんだ」という反応でした。 ポインタ完全制覇の初版が出てから17年、この点で違和感を表明したのは knwifuruさんが最初です(もちろん、表明しなかっただけで、違和感を感じていた人は いたのかもしれません)。 >しかし、もともと、endianというのは、「卵の尖った側(小さい側)から(先に)食べるか、 >丸い側(大きい側)から食べるか」=「bit/byte列のlower bits側が先に(lower addressに) >置かれるか、higher bitsが先に置かれるか」という事のようなので、 >数字を印刷・表示した時・読んだ時に先に・早く出てくるかどうか?で議論をすると、 >混乱すると思うのですが、いかがでしょうか? まあこれはendianを知らない人向けの説明なので、「もともとendianというのは～」で 説明してもあまり意味はなく、「数字を印刷・表示した時・読んだ時」の順と 逆になっていることから、「そんなこともあるんだ、へー」と思ってもらえば よいかと思っています。 「へー、逆なんだ」と思わない人は、knwifuruさんの他にもいるのかもしれませんし、 実のところどっちが多数派なのかもわかりませんが、本の書き手としては、 「想定読者は過去の自分自身」という視点から逃れられないものなのかもしれません。

ありがとうございます、納得しました！ >>HenacatでRunnableをimplementsしているのはServerThreadだけだと思いますが、 >>もしかしてマルチスレッドの各スレッドから呼び出されるクラスは、ルールの適用無しでも >>（結果として）マルチスレッドで動くという事なのでしょうか？ > >もちろん、マルチスレッドの各スレッドから呼び出されるメソッドは >呼び出し元のスレッドで動きますから、マルチスレッドで動きます。 >(クラスとかインスタンスは、この際関係ないですね) >

>HenacatでRunnableをimplementsしているのはServerThreadだけだと思いますが、 >もしかしてマルチスレッドの各スレッドから呼び出されるクラスは、ルールの適用無しでも >（結果として）マルチスレッドで動くという事なのでしょうか？ もちろん、マルチスレッドの各スレッドから呼び出されるメソッドは 呼び出し元のスレッドで動きますから、マルチスレッドで動きます。 (クラスとかインスタンスは、この際関係ないですね)

ついでに申せば、第1版のFig.3-3の「1加算するとここを指す」という説明も、よくわかりません。どういう意味でしょうか？何に1加算すると？ >2-3-2ポインタ型派生で(第1版p151、第2版p172)、「くどいようですが繰り返しておきます。ポインタに対して加算を行うと、そのポインタの指す型のサイズだけ、ポインタが進むのでした。」とありますが、ポインタの指す型のサイズだけ進むのは、(通常のポインタの実装では)【アドレス】であって、ポインタが進む大きさは、ポインタに加算した量だけ、ではないでしょうか?

なるほど、了解です！ありがとうございます。 ですが、もう少し分からないことがあります。 マルチスレッドで動くとなると、クラスがRunnableをimplementsして...のような ルールが必要なのかと思っていたのですが、HttpServletは、そのようになっていません。 HenacatでRunnableをimplementsしているのはServerThreadだけだと思いますが、 もしかしてマルチスレッドの各スレッドから呼び出されるクラスは、ルールの適用無しでも （結果として）マルチスレッドで動くという事なのでしょうか？ 入門書を読め！という話なのかも知れませんが、どうぞ宜しくお願いします。 >>分からないのは「info.servlet」がnullでなければ、同じインスタンスが >>使いまわされるのに、並行して複数個所から使いまわされていいんだっけ？ >>ということです。 > >p.92の補足にも書きましたが、サーブレットのインスタンスはひとつだけ生成され、 >すべてのリクエストで共有されます。 >よって、インスタンスフィールドを使えば、複数のスレッド間で競合が起きる >可能性がありますし、(補足にも書いたように)リクエスト単位やユーザ単位で >持つべき情報をサーブレットのインスタンスフィールドで保持してはいけません。 > >ただし、ローカル変数はスレッドごとに存在するので、ローカル変数(メソッドの >引数含む)だけを使っている限り、同じインスタンスのメソッドを複数のスレッドで >呼び出すことは問題ありません。 >

2-3-2ポインタ型派生で(第1版p151、第2版p172)、「くどいようですが繰り返しておきます。ポインタに対して加算を行うと、そのポインタの指す型のサイズだけ、ポインタが進むのでした。」とありますが、ポインタの指す型のサイズだけ進むのは、(通常のポインタの実装では)【アドレス】であって、ポインタが進む大きさは、ポインタに加算した量だけ、ではないでしょうか?

第1版p135, 第2版p156の、byteorder.cの実行直後の文、『私の環境では「0x12345678」という値は、メモリ上に、逆向きに配置されているようですね。』とあるのですが、何とは「逆向き」に、なのかがわかりません。何と逆向きなのでしょうか? (ぱ)さんの環境(little endian)で、78->56->34->12と表示されている、というのは、下の位から上の位にメモリアドレスが増えていっているので、僕には、逆ではなく【順に】に思えるのです。 数字の左から右(読む向き)とは【逆】という事でしょうか?　確かに、それとは逆ではありますが… しかし、もともと、endianというのは、「卵の尖った側(小さい側)から(先に)食べるか、丸い側(大きい側)から食べるか」=「bit/byte列のlower bits側が先に(lower addressに)置かれるか、higher bitsが先に置かれるか」という事のようなので、数字を印刷・表示した時・読んだ時に先に・早く出てくるかどうか?で議論をすると、混乱すると思うのですが、いかがでしょうか?

>分からないのは「info.servlet」がnullでなければ、同じインスタンスが >使いまわされるのに、並行して複数個所から使いまわされていいんだっけ？ >ということです。 p.92の補足にも書きましたが、サーブレットのインスタンスはひとつだけ生成され、 すべてのリクエストで共有されます。 よって、インスタンスフィールドを使えば、複数のスレッド間で競合が起きる 可能性がありますし、(補足にも書いたように)リクエスト単位やユーザ単位で 持つべき情報をサーブレットのインスタンスフィールドで保持してはいけません。 ただし、ローカル変数はスレッドごとに存在するので、ローカル変数(メソッドの 引数含む)だけを使っている限り、同じインスタンスのメソッドを複数のスレッドで 呼び出すことは問題ありません。

いつもお世話になっております。おかげさまで安心して読み進めることが出来ます。 『基礎からのWebアプリケーション開発入門』のP.116のリスト3-17の76行目に info.servlet.service(req,resp); という行があります。 この「info.servlet」はnullであれば53行目でインスタンスを作っています。 また「info.servlet」はWebapplicationのメンバーなので、当然、複数箇所から並行して呼ばれることがあるのではないかと思います。 分からないのは「info.servlet」がnullでなければ、同じインスタンスが使いまわされるのに、並行して複数個所から使いまわされていいんだっけ？ということです。 これは、マルチスレッド的な何か仕掛けがあって、このような作りになっているのでしょうか？ 初心者で分からないことが多く、ご迷惑をおかけします。もしかして、ものすごく曖昧な質問なのかも知れませんが、よろしければお教えください。

ご回答ありがとうございました。理解できました。 こんなにレスポンスが早く、直接、著者より回答がいただけるのは、非常にありがたいです。