Link:

---

はじめまして。

>180ページのTable3-3でint *hoge[10]のサイズが8×10になっていますが
>int型の配列へのポインタなので4×10ではないでしょうか？

int *hoge[10]は、そのページの説明にもあるとおり、
「int型へのポインタの配列(要素数10)」です。
ポインタのサイズは処理系依存ですが、その前のページでポインタは8バイトと
仮定しているので、8×10で80バイトです。

なお、「int型の配列へのポインタ」であれば、(指す先は何であれポインタなので)
8バイトになりますね。

Link:

---

最近貴書を購入しました。
一つ質問があります。
180ページのTable3-3でint *hoge[10]のサイズが8×10になっていますがint型の配列へのポインタなので4×10ではないでしょうか？
よろしくお願いいたします。

Link:

---

すみません、自己解決しました。
Eclipseがコンパイル時にデフォルトで使用するバージョンがJavaSE11になっていたので、CokkieTestもreleaseオプションで指定で同バージョンにすることで解決致しました。

（というかそもそもスタックトレース見ろレベルの質問でした、大変失礼致しました。）

Link:

---

はじめまして。
>URL（http://localhost:8001/testbbs/ShowBBS）を入力したところでclassLoaderが例外を発生させてしまいました。

具体的なスタックトレースがわからないので何ですが、
もし起きているのがClassNotFoundExceptionだったとすると、
ShowBBSのクラスが所定の場所にないのではないでしょうか。

Henacatの場合、Henacat自体のソースやクラスをどこに置くかに関係なく、
サーブレットのクラスは、WebApplication.javaの8行目、

private static String WEBAPPS_DIR = "C:\\Henacat_0_1\\webapps";

この場所に置いてあることを期待しています。

もっとも、ここに置いてないならEclipseでなくても動かないですし、

>ShowBBS等のクラスパス指定もElicpseのプロジェクト配下のクラスパスを
>指定してコンパイルしています。

というのは、「3.4.3 Henacat ver.0.1 で掲示板を動かす」の
| この修正を加えたうえで、Henacatのクラスファイルのルートである
| com ディレクトリが存在するディレクトリ（「com\ kmaebashi\henacat\……」と
| いうディレクトリ階層の根元）にclasspathを向けてコンパイルし、
| クラスファイルを作ります。

という記載に沿っていることを意味するのであれば、そのあたりも
当然分かったうえで実行されているように思います。

あとは、具体的な例外を見てみないと、ちょっとわかりません。

Link:Eclipseを使うとclassLoaderで例外が発生

---

こんばんは、本質的なところと全く違うので恐縮ですが、
「Webサーバを作りながら学ぶ 基礎からのWebアプリケーション開発入門」の第3章にて実装したHenacat0_1の挙動について質問となります。 

Henacat0_1のソースコードをダウンロードし、
コマンドプロンプトにてコンパイルを通してMainを実行したところ、
特に問題なく掲示板が稼動しました。

ところが、同ソースコードをEclipseで作成したJavaプロジェクトにコピペしてMainを実行したところ、
URL（http://localhost:8001/testbbs/ShowBBS）を入力したところでclassLoaderが例外を発生させてしまいました。
（デバッグ実行させたところ、WebApplicationインスタンスやServletInfoインスタンスは値を渡せているように見えます）
Eclipseはデフォルト文字コードがUTF-8ですが、本プロジェクトについては個別設定でsjisを設定しているので文字コードは問題ないかと思うのですが。。。
また、binフォルダを見ても無名クラス含めてクラアスファイルはしっかり作成されていますし、ShowBBS等のクラスパス指定もElicpseのプロジェクト配下のクラスパスを指定してコンパイルしています。

文字コードとコンパイルミス以外に考えられる原因等はありますでしょうか？

Link:

---

返信が遅れて申し訳ありません。

>書籍の中の補足でNULLマクロは処理系によって定義のされ方が違うと書かれていましたが、
>(void*)0であっても0であってもNULLは真偽値で言えば偽が返る値ということですね。

その通りです。これについてはC FAQに記載がありました。

http://www.kouno.jp/home/c_faq/c5.html#3
| 5.3:
| ポインターがヌルポインターでないかどうかのテストの省略形 「if(p)」は有効なのか? 
| ヌルポインターの内部表現が0でない場合は どうなるのか。
| A:
| C言語が式のブール値を必要とする場合(if、while、forやdo文において、
| また&&、||、!、?:演算子と共に使う場合)、0と比較して等しい場合は偽の値が
| 産み出され、その他の場合は真が産み出される。すなわち
|
|    if(expr)
|
| と書いたらいつも、「expr」がどんな式かにかかわらずコンパイラは必ず
|
|    if((expr) != 0)
|
| と書かれたように基本的には動作する。

Link:

---

書籍の中の補足でNULLマクロは処理系によって定義のされ方が違うと書かれていましたが、(void*)0であっても0であってもNULLは真偽値で言えば偽が返る値ということですね。

本日読了しました。初心者だったので4章以降の実践的な部分は難しく感じる部分もありましたが、何度も読み返していくことでかなりの部分を理解できたと思います。
入門書を読んだだけで理解が曖昧だったポインタや配列、変数の分類や構造体などのC言語の文法についても改めて整理できました。本書のテーマはC言語のポインタですが、結果的にはC言語の文法全体に触れるような構成になっているのはそれだけC言語とポインタが深く広く結びついているということですね。

長くなりましたが技術書ながらとても読みやすく勉強になる本でした。質問にも丁寧に答えていただきありがとうございました。

Link:

---

stdinも含めてFILE構造体には、ファイルが終端に達したことを示すフラグがあって、そのフラグが立っている場合にはfgetc()で取り出される値はEOFになるということですね。
納得できました。ありがとうございます。

Link:

---

>P.297 List 5-14 11行目で、for文の終了条件にposとあるのですが、
>これは pos != NULL ではないでしょうか。

Cでは0以外は全部真なので、条件式にposと書いてもpos != NULLと書いても
意味は同じです。
Cプログラマは使いがちな書き方ではありますが、p.57の「ポインタ演算なんか
使うのはやめてしまおう」のところで『「一見してわかりにくいように見える」なら、
やっぱり書くべきではないでしょう』とか書いてる本としては
ちょっとダブルスタンダードっぽいかな、とは我ながら思わなくもないです (^^;

Link:

---

あれ、昨晩返信したつもりなのに投稿されていませんでした。

>それとも標準入力において一度EOFが入力されたら、以降標準入力から取り出される値は
>EOFとなることが決まっているのでしょうか。

こちらです。

規格では(マクロであることを除き)getc()はfgetc()と等価とされていますが、
そのfgetc()の説明には以下のようにあります。

| 返却値　そのストリームのファイル終了表示子がセットされている場合，
| 又はストリームがファイルの終わりに達している場合，そのストリームの
| ファイル終了表示子をセットし，fgetc 関数は，EOF を返す。

つまり、FILE構造体には「ファイル終了表示子」というフラグがあり、
ファイルの最後に達するとそれがセットされて、以後はEOFを返します。

Link:

---

お忙しい中ご返信ありがとうございます。

度々申し訳ないのですが、確認させていただきたい所がございます。

P.297 List 5-14 11行目で、for文の終了条件にposとあるのですが、これは pos != NULL ではないでしょうか。

Link:

---

>はじめまして。

はじめまして。読んでいただきありがとうございます。

>p.114 List2-6 12行目
>コメントとの対応を考えると、%edではなく%edxではないでしょうか。

そうですね。オリジナルのソースを見ると%edxになっているので、
編集段階で(矢印を入れたときに?)xが消えてしまったようです。
確認不足でした。申し訳ありません。

>p.226 10の後の英語的表現
>英文の2行目最後のfucntion(int)の後に閉じ括弧)がありますが、
>不要ではないでしょうか。

こちらもそのとおりです。申し訳ありません。

ご指摘ありがとうございました。後ほど正誤表に入れさせていただきます。

Link:

---

重ねて質問させていただきます。
C言語ポインタ完全制覇 P.243-246 の、read_line()関数を、引数にstdinを渡して呼び出す部分について聞かせていただきたいです。

例えば標準入力から、
abcd[Enter]
ef[EOF]
というように入力すると、read_line()関数は、P.244 List4-6 の61-75行目の処理で、
まず"abcd\0"を返し、次にline_bufferが"ef"になったところでchがEOFとなるので61行目のwhileを抜けて69行目に進み、結果"ef\0"を返します。

この時点でまだNULLを返さないので、main()関数のwhileは次のループに入り、再びread_line()関数にstdinを渡して呼び出すこととなりますが、この時に61行目のgetc(fp)で取り出される値は何なのでしょうか。

実験してみると、どうもこの段階でEOF(だけ)を取り出していて72行目に進み、read_line()関数がNULLを返しているようなのですが、標準入力においてキーアクションのEOFの後に続けて入力を行うことが可能ならば、getc(fp)でその入力値を受け取ってしまうということはないのでしょうか。

それとも標準入力において一度EOFが入力されたら、以降標準入力から取り出される値はEOFとなることが決まっているのでしょうか。

Link:

---

はじめまして。
C言語ポインタ完全制覇(初版　第一刷)の内容についていくつか確認させていただきたいです。

C言語勉強中、アセンブリ言語については全く知らない身なので、見当外れな質問でしたら申し訳ないです。

p.114 List2-6 12行目
コメントとの対応を考えると、%edではなく%edxではないでしょうか。

p.226 10の後の英語的表現
英文の2行目最後のfucntion(int)の後に閉じ括弧)がありますが、不要ではないでしょうか。

Link:

---

ご連絡ありがとうございます。

正誤表を確認しました。
ご対応、ありがとうございました。

Link:

---

はじめまして。遅くなりましてすみません。

>330ページにある、
>void (*draw_shape_func_table)(Shape *shape)[]
>というのは、誤植ではないでしょうか？
>正しくは、
>void (*draw_shape_func_table[])(Shape *shape)
>だと思います。

確認しました。これはこの本のテーマにもろに重なっているという点で
かなりまずいミスでした。申し訳ありません。
「わからない人は3章を読み返しましょう」って書いてあるのが
我ながら余計に痛いです。

正誤表に載せておきます。ご指摘ありがとうございました。

Link:

---

前橋和弥様

改訂版のC言語ポインタ完全制覇を読んだものです。
非常にためになる本で、常日頃参考にさせて頂いております。
今回は、この本に誤植らしきものがあるので、ご連絡致しました。

330ページにある、
void (*draw_shape_func_table)(Shape *shape)[]
というのは、誤植ではないでしょうか？
正しくは、
void (*draw_shape_func_table[])(Shape *shape)
だと思います。
前者だとコンパイルが通りませんでした。

以上、確認をお願い致します。

Link:

---

>ぱさんの本で自分がポインターの何が解っていないか初めて解り
>大変良い物だとありがたい限りです

はじめまして。読んでいただきありがとうございます。

>ところで次のような物を見つけたのでご存じなければつまみにでもどうぞ
>https://cdecl.org/

紹介ありがとうございます。初めて知りました。
ポインタ完全制覇でも取り上げた、K&Rに載っているdclのWeb版ですね。
Webで簡単に解析できるのは便利なので、あとはひっくり返して日本語に
してくれれば…… と思うのですが、自分で作れと言われそう。
時間があれば、作ってみたい気はするのですが。

Link:

---

こんばんは

ぱさんの本で自分がポインターの何が解っていないか初めて解り
大変良い物だとありがたい限りです

ところで次のような物を見つけたのでご存じなければつまみにでもどうぞ
https://cdecl.org/

Link:

---

>レスが付かないまま１週間以上たってしまったため、自己レスします。 

すみません、最近どたばたしておりまして、ちょっと気力がたまりませんでした。

>で、パケット解析をするとすぐわかりますが、ブラウザから
[ http://localhost:8001/日本語 ] ;でアクセスすると、
>サーバからレスポンスコード301が返ってきており、
>そこで指定されている移動先URLが文字化けしています。 

なるほど…… これはさすがに気付いてしかるべきでしたね。
パケットキャプチャやFiddlerどころか、F12開発者ツールでわかるレベルの話です。

言い訳しますと、

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

…という確認をしていたのにリクエストは1回ずつしか来なかったので、
リダイレクトは想定しませんでした。最初の1回はちゃんと飛んでたはずですが
(過去投稿を見るとIEではそうだったとの記載もある)、今F12を入れて見てみると、
2回目以後はキャッシュされてますね。
「F12開発者ツール」とか、「変な動きがあればキャッシュを消せ」あたりは
Webアプリ開発の基本ですが、どうもぼけてたようです。

Link:

---

削除パスワードを設定していなかったため修正も削除もできないため返信します。
前回の発言、一部間違っていました。ダウンロードしたのは再現テストの前、一番最初です。

Link:

---

レスが付かないまま１週間以上たってしまったため、自己レスします。 
> さすがにどっかで化けているとしたらブラウザだと思うのですが 
思い込みの罠にはまっています。というか傍から見ると自分でフラグ立てていますよ。 

fidderをプロキシとしてブラウザとサーバの間に挟むと若干動きが変わりますが、パケット解析には問題ないです。 
で、パケット解析をするとすぐわかりますが、ブラウザから[ http://localhost:8001/日本語 ]でアクセスすると、サーバからレスポンスコード301が返ってきており、そこで指定されている移動先URLが文字化けしています。 ;

で、（サポートページから勝手にソースをダウンロードして）問題箇所を見ると、ServerThread.javaのpathの扱いが不注意なところがありました。 
まず、25行目で、urldecodeプラスアルファ的なことをしていて、url文字列からPCで扱う文字列にしています。 
その後、54行目で、移動先ページの組み立てで、PCで扱う文字列となっているpathを(url文字列形式にせずに)そのまま使っています。 
urlデコードしてもしなくても変わらない文字列であれば問題が起きなかったのですが、今回はそのケースではないためエラーが見つかっちゃったんだと思います。 
仮に56行目 [ + path + "/"; ]の部分を[ + "/%E6%97%A5%E6%9C%AC%E8%AA%9E/"; ]に書き換えれば意図通りにいっているように見えるんじゃないかな？ 

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