K.Maebashi's BBS

ご自由に書き込んでください。雑談も可。
テスト書き込みの類はテスト用掲示板にどうぞ

[日付順表示] [日付順インデックス] [スレッド順インデックス]

新規投稿 | 開設者ホームページへ戻る | ヘルプ

[2176] C言語ポインタ完全制覇
投稿者:かずぼん
2019/05/18 08:55:14

最近貴書を購入しました。 一つ質問があります。 180ページのTable3-3でint *hoge[10]のサイズが8×10になっていますがint型の配列へのポインタなので4×10ではないでしょうか? よろしくお願いいたします。
[この投稿を含むスレッドを表示] [この投稿を削除]
[2175] Re:Eclipseを使うとclassLoaderで例外が発生
投稿者:Radec
2019/05/12 09:33:25

すみません、自己解決しました。 Eclipseがコンパイル時にデフォルトで使用するバージョンがJavaSE11になっていたので、CokkieTestもreleaseオプションで指定で同バージョンにすることで解決致しました。 (というかそもそもスタックトレース見ろレベルの質問でした、大変失礼致しました。)
[この投稿を含むスレッドを表示] [この投稿を削除]
[2174] Re:Eclipseを使うとclassLoaderで例外が発生
投稿者:(ぱ)こと管理人
2019/05/08 23:34:30

はじめまして。 >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を向けてコンパイルし、 | クラスファイルを作ります。 という記載に沿っていることを意味するのであれば、そのあたりも 当然分かったうえで実行されているように思います。 あとは、具体的な例外を見てみないと、ちょっとわかりません。
[この投稿を含むスレッドを表示] [この投稿を削除]
[2173] 無題
投稿者:Radec
2019/05/07 21:33:35

こんばんは、本質的なところと全く違うので恐縮ですが、 「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のプロジェクト配下のクラスパスを指定してコンパイルしています。 文字コードとコンパイルミス以外に考えられる原因等はありますでしょうか?
[この投稿を含むスレッドを表示] [この投稿を削除]
[2172] Re:c言語ポインタ完全制覇(改訂版)に関する質問
投稿者:(ぱ)こと管理人
2019/04/02 01:25:35

返信が遅れて申し訳ありません。 >書籍の中の補足で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) | | と書かれたように基本的には動作する。
[この投稿を含むスレッドを表示] [この投稿を削除]
[2171] Re:c言語ポインタ完全制覇(改訂版)に関する質問
投稿者:f_ki
2019/03/28 14:41:19

書籍の中の補足でNULLマクロは処理系によって定義のされ方が違うと書かれていましたが、(void*)0であっても0であってもNULLは真偽値で言えば偽が返る値ということですね。 本日読了しました。初心者だったので4章以降の実践的な部分は難しく感じる部分もありましたが、何度も読み返していくことでかなりの部分を理解できたと思います。 入門書を読んだだけで理解が曖昧だったポインタや配列、変数の分類や構造体などのC言語の文法についても改めて整理できました。本書のテーマはC言語のポインタですが、結果的にはC言語の文法全体に触れるような構成になっているのはそれだけC言語とポインタが深く広く結びついているということですね。 長くなりましたが技術書ながらとても読みやすく勉強になる本でした。質問にも丁寧に答えていただきありがとうございました。
[この投稿を含むスレッドを表示] [この投稿を削除]
[2170] Re:C言語の標準入力とEOFの扱いについて
投稿者:f_ki
2019/03/28 14:24:48

stdinも含めてFILE構造体には、ファイルが終端に達したことを示すフラグがあって、そのフラグが立っている場合にはfgetc()で取り出される値はEOFになるということですね。 納得できました。ありがとうございます。
[この投稿を含むスレッドを表示] [この投稿を削除]
[2169] Re:c言語ポインタ完全制覇(改訂版)に関する質問
投稿者:(ぱ)こと管理人
2019/03/28 00:12:29

>P.297 List 5-14 11行目で、for文の終了条件にposとあるのですが、 >これは pos != NULL ではないでしょうか。 Cでは0以外は全部真なので、条件式にposと書いてもpos != NULLと書いても 意味は同じです。 Cプログラマは使いがちな書き方ではありますが、p.57の「ポインタ演算なんか 使うのはやめてしまおう」のところで『「一見してわかりにくいように見える」なら、 やっぱり書くべきではないでしょう』とか書いてる本としては ちょっとダブルスタンダードっぽいかな、とは我ながら思わなくもないです (^^;
[この投稿を含むスレッドを表示] [この投稿を削除]
[2168] Re:C言語の標準入力とEOFの扱いについて
投稿者:(ぱ)こと管理人
2019/03/28 00:05:43

あれ、昨晩返信したつもりなのに投稿されていませんでした。 >それとも標準入力において一度EOFが入力されたら、以降標準入力から取り出される値は >EOFとなることが決まっているのでしょうか。 こちらです。 規格では(マクロであることを除き)getc()はfgetc()と等価とされていますが、 そのfgetc()の説明には以下のようにあります。 | 返却値 そのストリームのファイル終了表示子がセットされている場合, | 又はストリームがファイルの終わりに達している場合,そのストリームの | ファイル終了表示子をセットし,fgetc 関数は,EOF を返す。 つまり、FILE構造体には「ファイル終了表示子」というフラグがあり、 ファイルの最後に達するとそれがセットされて、以後はEOFを返します。
[この投稿を含むスレッドを表示] [この投稿を削除]
[2167] Re:c言語ポインタ完全制覇(改訂版)に関する質問
投稿者:f_ki
2019/03/27 21:55:06

お忙しい中ご返信ありがとうございます。 度々申し訳ないのですが、確認させていただきたい所がございます。 P.297 List 5-14 11行目で、for文の終了条件にposとあるのですが、これは pos != NULL ではないでしょうか。
[この投稿を含むスレッドを表示] [この投稿を削除]
[2166] Re:c言語ポインタ完全制覇(改訂版)に関する質問
投稿者:(ぱ)こと管理人
2019/03/27 01:20:56

>はじめまして。 はじめまして。読んでいただきありがとうございます。 >p.114 List2-6 12行目 >コメントとの対応を考えると、%edではなく%edxではないでしょうか。 そうですね。オリジナルのソースを見ると%edxになっているので、 編集段階で(矢印を入れたときに?)xが消えてしまったようです。 確認不足でした。申し訳ありません。 >p.226 10の後の英語的表現 >英文の2行目最後のfucntion(int)の後に閉じ括弧)がありますが、 >不要ではないでしょうか。 こちらもそのとおりです。申し訳ありません。 ご指摘ありがとうございました。後ほど正誤表に入れさせていただきます。
[この投稿を含むスレッドを表示] [この投稿を削除]
[2165] C言語の標準入力とEOFの扱いについて
投稿者:f_ki
2019/03/26 20:40:41

重ねて質問させていただきます。 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となることが決まっているのでしょうか。
[この投稿を含むスレッドを表示] [この投稿を削除]
[2164] c言語ポインタ完全制覇(改訂版)に関する質問
投稿者:f_ki
2019/03/25 17:29:45

はじめまして。 C言語ポインタ完全制覇(初版 第一刷)の内容についていくつか確認させていただきたいです。 C言語勉強中、アセンブリ言語については全く知らない身なので、見当外れな質問でしたら申し訳ないです。 p.114 List2-6 12行目 コメントとの対応を考えると、%edではなく%edxではないでしょうか。 p.226 10の後の英語的表現 英文の2行目最後のfucntion(int)の後に閉じ括弧)がありますが、不要ではないでしょうか。
[この投稿を含むスレッドを表示] [この投稿を削除]
[2163] Re:C言語ポインタ完全制覇について
投稿者:d_kuma
2019/03/22 17:33:36

ご連絡ありがとうございます。 正誤表を確認しました。 ご対応、ありがとうございました。
[この投稿を含むスレッドを表示] [この投稿を削除]
[2162] Re:C言語ポインタ完全制覇について
投稿者:(ぱ)こと管理人
2019/03/21 15:18:41

はじめまして。遅くなりましてすみません。 >330ページにある、 >void (*draw_shape_func_table)(Shape *shape)[] >というのは、誤植ではないでしょうか? >正しくは、 >void (*draw_shape_func_table[])(Shape *shape) >だと思います。 確認しました。これはこの本のテーマにもろに重なっているという点で かなりまずいミスでした。申し訳ありません。 「わからない人は3章を読み返しましょう」って書いてあるのが 我ながら余計に痛いです。 正誤表に載せておきます。ご指摘ありがとうございました。
[この投稿を含むスレッドを表示] [この投稿を削除]
[2161] C言語ポインタ完全制覇について
投稿者:d_kuma
2019/03/18 13:40:27

前橋和弥様 改訂版のC言語ポインタ完全制覇を読んだものです。 非常にためになる本で、常日頃参考にさせて頂いております。 今回は、この本に誤植らしきものがあるので、ご連絡致しました。 330ページにある、 void (*draw_shape_func_table)(Shape *shape)[] というのは、誤植ではないでしょうか? 正しくは、 void (*draw_shape_func_table[])(Shape *shape) だと思います。 前者だとコンパイルが通りませんでした。 以上、確認をお願い致します。
[この投稿を含むスレッドを表示] [この投稿を削除]
[2160] Re:ちょっとした事
投稿者:(ぱ)こと管理人
2019/03/13 01:56:14

>ぱさんの本で自分がポインターの何が解っていないか初めて解り >大変良い物だとありがたい限りです はじめまして。読んでいただきありがとうございます。 >ところで次のような物を見つけたのでご存じなければつまみにでもどうぞ >https://cdecl.org/ 紹介ありがとうございます。初めて知りました。 ポインタ完全制覇でも取り上げた、K&Rに載っているdclのWeb版ですね。 Webで簡単に解析できるのは便利なので、あとはひっくり返して日本語に してくれれば…… と思うのですが、自分で作れと言われそう。 時間があれば、作ってみたい気はするのですが。
[この投稿を含むスレッドを表示] [この投稿を削除]
[2159] ちょっとした事
投稿者:冷水
2019/03/11 03:34:50

こんばんは ぱさんの本で自分がポインターの何が解っていないか初めて解り 大変良い物だとありがたい限りです ところで次のような物を見つけたのでご存じなければつまみにでもどうぞ https://cdecl.org/
[この投稿を含むスレッドを表示] [この投稿を削除]
[2158] Re:Modoki/0.2のリダイレクトの処理について
投稿者:(ぱ)こと管理人
2019/02/24 20:00:11

>レスが付かないまま1週間以上たってしまったため、自己レスします。 すみません、最近どたばたしておりまして、ちょっと気力がたまりませんでした。 >で、パケット解析をするとすぐわかりますが、ブラウザから [ http://localhost:8001/日本語 ] でアクセスすると、 >サーバからレスポンスコード301が返ってきており、 >そこで指定されている移動先URLが文字化けしています。 なるほど…… これはさすがに気付いてしかるべきでしたね。 パケットキャプチャやFiddlerどころか、F12開発者ツールでわかるレベルの話です。 言い訳しますと、 >SenderThread.javaの24行目に、以下のようにSystem.out.println()を挟んで確認しました。 …という確認をしていたのにリクエストは1回ずつしか来なかったので、 リダイレクトは想定しませんでした。最初の1回はちゃんと飛んでたはずですが (過去投稿を見るとIEではそうだったとの記載もある)、今F12を入れて見てみると、 2回目以後はキャッシュされてますね。 「F12開発者ツール」とか、「変な動きがあればキャッシュを消せ」あたりは Webアプリ開発の基本ですが、どうもぼけてたようです。
[この投稿を含むスレッドを表示] [この投稿を削除]
[2157] Re:Modoki/0.2のリダイレクトの処理について
投稿者:mano
2019/02/22 23:53:22

削除パスワードを設定していなかったため修正も削除もできないため返信します。 前回の発言、一部間違っていました。ダウンロードしたのは再現テストの前、一番最初です。
[この投稿を含むスレッドを表示] [この投稿を削除]
[2156] Re:Modoki/0.2のリダイレクトの処理について
投稿者:mano
2019/02/22 23:30:27

レスが付かないまま1週間以上たってしまったため、自己レスします。 > さすがにどっかで化けているとしたらブラウザだと思うのですが 思い込みの罠にはまっています。というか傍から見ると自分でフラグ立てていますよ。 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/"; ]に書き換えれば意図通りにいっているように見えるんじゃないかな?
[この投稿を含むスレッドを表示] [この投稿を削除]
[2155] Re:Modoki/0.2のリダイレクトの処理について
投稿者:Radec
2019/02/14 23:47:50

なるほど。。。 確かに自分で実装したTcpClientなら余計な補正は働きませんね。 動作確認できました。ありがとうございました。
[この投稿を含むスレッドを表示] [この投稿を削除]
[2154] Re:Modoki/0.2のリダイレクトの処理について
投稿者:mano
2019/02/13 20:17:34

最初からガッツリ調べなくても最初はfiddlerでいいんじゃない?appgoatの学習でも使っているツールだし。。。
[この投稿を含むスレッドを表示] [この投稿を削除]
[2153] Re:Modoki/0.2のリダイレクトの処理について
投稿者:(ぱ)こと管理人
2019/02/13 02:39:34

ごぶさたしてます。 >なので、問題となった%E5,%9Eは、日本語をUnicode符合位置で求めた場合の >下位1バイト分に相当します。 あ、気付いていませんでしたが確かにそうですね。 だとしても、なぜ「日本語」の場合だけそうなるのは謎ですが…… 本件、Modoki/0.2はただソケットでデータを受け取るだけなので、 さすがにどっかで化けているとしたらブラウザだと思うのですが、 パケットフィルタリングもちょっと考えてみます。(今でもWiresharkで よかったんだっけ…?)
[この投稿を含むスレッドを表示] [この投稿を削除]
[2152] Re:Modoki/0.2のリダイレクトの処理について
投稿者:(ぱ)こと管理人
2019/02/13 02:26:13

>過去の例にあったような「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)) { 側の処理に流れ込むことが確認できます。
[この投稿を含むスレッドを表示] [この投稿を削除]
[2151] Re:Modoki/0.2のリダイレクトの処理について
投稿者:mano
2019/02/12 20:11:03

本を持っていないため、推測となってしまいますし、外しているかもしれませんが。。。 日本語のそれぞれの文字のUnicode符合位置は、[日]=U+65E5、[本]=U+672C、[語]=U+8A9Eです。 また、「,」は、Unicode符合位置がU+002Cです。 なので、問題となった%E5,%9Eは、日本語をUnicode符合位置で求めた場合の下位1バイト分に相当します。 この辺を手がかりに、パケットキャプチャすればどのタイミングまでは文字コードが意図通りとなっているかがのあたりがつくかもです。
[この投稿を含むスレッドを表示] [この投稿を削除]
[2150] Re:Modoki/0.2のリダイレクトの処理について
投稿者:Radec
2019/02/11 23:20:50

こんばんは。 早々にご確認・ご回答頂きまして、まことにありがとうございます。 当方でも様々な文字で確認してみましたが、やはり上手くいくときといかないときがあり、よくわからない結果となってしまいました。 ブラウザ等の仕様に起因するところもあるかと思うので厳密には分からないかとは思いますが、もともとの目的である動き・仕様は理解できたので先に進もうかと思います。 ちなみに、また別の質問となってしまい恐縮ですが、 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が発生することが自然な動きのようにも思えます。 以上、よろしくお願いいたします。
[この投稿を含むスレッドを表示] [この投稿を削除]
[2149] Re:Modoki/0.2のリダイレクトの処理について
投稿者:(ぱ)こと管理人
2019/02/11 19:53:57

はじめまして。ご質問いただきありがとうございます。 >入力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);
[この投稿を含むスレッドを表示] [この投稿を削除]
[2148] Modoki/0.2のリダイレクトの処理について
投稿者:Radec
2019/02/11 11:45:33

はじめまして。 「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は発生していません。 このような差異が発生してしまう要因として考えられることはどのようなものでしょうか?
[この投稿を含むスレッドを表示] [この投稿を削除]
[2147] Re:サイト内のリンク切れ
投稿者:(ぱ)こと管理人
2019/01/01 20:21:16

>webサーバを作ってみようページの以下リンクが切れております。 ありえないほど遅くなりましたが、ご指摘ありがとうございます。 とはいえよそのページなので消えるときは消えますし、それについて私にできることは 特にないよなー、と思ったのですが、Wayback Machineの存在を思い出したので そちらに張りなおしておきました。
[この投稿を含むスレッドを表示] [この投稿を削除]