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

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のことですよね。
１回のリクエストでこれらが複数になる場合というのがどうもよくわかりません。

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