K.Maebashi's BBS

お疲れ様です。 先生のご指摘の通り、「!isalnum(ch)」となっていました。 この部分を修正し、動作させると実行結果は「ABCDE　１」となりました。 ありがとうございます。 ＜修正前のget_word.c＞ int get_word(char* buf, int buf_size, FILE* fp) { int len; int ch = 0; /* 空白文字の読み飛ばし */ while (((ch = getc(fp)) != EOF) && !isalnum(ch)) { ; } if (ch == EOF) { return EOF; } /* ここで、chには、単語の最初の文字が格納されている */ len = 0; do { buf[len] = ch; len++; if (len >= buf_size) { /* 単語が長すぎるためエラー */ fprintf(stderr, "word too long\n"); exit(1); } } while (((ch = getc(fp)) != EOF) && !isalnum(ch)); //ミス！！！！ buf[len] = '\0'; return len; }

はじめまして。ご質問ありがとうございます。 >＜読み込ませたtxtファイルの中身＞ >ABCDE > >＜出力結果＞ >A 1 >C 1 >E 1 > >※なぜか1個飛ばしで結果が表示される。 このプログラムは「単語の」出現頻度を数えるプログラムであって、文字の出現頻度を 数えるものではないので、これは「1個飛ばし」ではありません。読み込ませたtxtファイルの 中身がABCDEなら、 ABCDE 1 が正しい出力結果です。 入力ファイルのエンコーディングがUTF16である可能性も考えましたが、その場合でも A 1 B 1 C 1 D 1 E 1 となりそうなものです(当方で試したらそうなりました)。 get_word.cがそちらで打ち込まれたものなら、それをそのままここに貼っていただけないでしょうか? 27: } while ((ch = getc(fp)) != EOF && isalnum(ch)); このあたりが怪しい気がします。isalnumの前に!がついているとか。

お世話になっております。 表題の件について、作成したword_count(配列版)をgccで実行しました。 すると出力結果が以下のようになりましたが、これで正しいのでしょうか？ ご確認よろしくお願いします。 ＜読み込ませたtxtファイルの中身＞ ABCDE ＜出力結果＞ A 1 C 1 E 1 ※なぜか1個飛ばしで結果が表示される。

>こんな時間帯に職場からアクセスされてたんですね……　(海外でしたっけ?) えへへ、その辺は略。 やはり MITM 串は悪。いや、巨悪っス。

どうもです。 >前回 DNS が落ちていた？と思った件は、ウチの社内からアクセスすると MITM 串の >関係でエラーメッセージが改変されてしまっているためのようでした。（サイトが >見つかりません） なるほど。しかし今回は(朝確認しなかったせいで)終日落ちっぱなしに してしまいましたが、前回は06:44～08:11の2時間たらずだったはずで、 こんな時間帯に職場からアクセスされてたんですね……　(海外でしたっけ?)

今回落ちていた件ですが、オイラのスマホのモバイル回線から確認すると DNS はちゃんと動いていて、でも httpd が落ちている症状でした。（接続が拒否されましたないしは空の応答がありました） 前回 DNS が落ちていた？と思った件は、ウチの社内からアクセスすると MITM 串の関係でエラーメッセージが改変されてしまっているためのようでした。（サイトが見つかりません） やはり MITM 串は悪。

1/23 06:30のdnf updateが原因のようです。 Apacheが再起動しない理由は分かっているので、近々対策します……

>何かが意図的にApacheをgraceful shutdownしようと >したのでしょうが、そこまでは追えていません。。 dnf historyで確認すると、11/20 06:41にdnfがかかった形跡はあるので、 それだと思うのですが、dnfで更新されたときはメールが飛ぶような設定にしてある はずが、このメールが来てないんですよねえ。

11/20 06:44:07に、ApacheがSIGWINCHを食らってシャットダウンしていたようです。 httpd/error_log:[Wed Nov 20 06:44:07.796734 2024] [mpm_event:notice] [pid 253266:tid 253266] AH00492: caught SIGWINCH, shutting down gracefully SIGWINCHというのはその名の通り端末のウインドウサイズを変えたときのシグナルで、 lessだのが表示を調整するために使うものですが、 Apacheはシグナルが足りないからってこれをgraceful shutdownに使っているらしい。 とはいえ私のサーバのApacheはバックグラウンドで動いているので、真の意味の SIGWINCHを食らうはずはなく、何かが意図的にApacheをgraceful shutdownしようと したのでしょうが、そこまでは追えていません。。 アクセスログを見ても11/20 06:43:58を最後に途切れています。

どうもです。いつもありがとうございます。 >症状的には DNS ないしは DDNS が落ちてた / 契約切れなどにより名前解決できて >なかったと見ました。 Apache HTTPD 再起動で直ったとはちょっと思えないです。 >その際に DNS/DDNS 類も再起動していたのでは？ 「名前解決できてなかった」というのはkmaebashi.comの名前が解決できていなかった のでは、ということでしょうか? 当日の朝、WebサイトはつながりませんでしたがSSHでログインすることはできていて、 SSHでログインする際は % ssh kmaebashi.com と打っていたので、名前解決はできていたと思います。 Apache再起動で直ったのでやはり何らかの原因でApacheが落ちていたのだと思いますが、 ここ数日ちょっとどたばたしているので週末に確認します。現状、何時から落ちていた のかさえ把握しておりませんので。 apache再起動時はTLS秘密鍵のパスフレーズを聞かれたので、それを入れない単なる OS再起動で復旧しなかったのはそのせいだと思いますが。 出勤前であわてていたとはいえ、せめてもうちょっとスクリーンショット等残しておく べきでした。 >んで、証明書期限切れエラーであってもメールは届くわけですが DNS エラーだと >メールも届かないわけですよね。一読者としてはそういう場合にどうやれば管理人に >連絡取れるんですかね＞ネットワーク詳しい人？ まあ、私の場合は、kmaebashi.comでメールは受け取っておらず公式のメールアドレスは Niftyにあるわけですが、kmaebashi.comが落ちてたらそのアドレスを見つけるのも 難しい、というのはあるかもしれません。

症状的には DNS ないしは DDNS が落ちてた / 契約切れなどにより名前解決できてなかったと見ました。 Apache HTTPD 再起動で直ったとはちょっと思えないです。その際に DNS/DDNS 類も再起動していたのでは？ んで、証明書期限切れエラーであってもメールは届くわけですが DNS エラーだとメールも届かないわけですよね。一読者としてはそういう場合にどうやれば管理人に連絡取れるんですかね＞ネットワーク詳しい人？

SSHでは入れたのでサーバ自体が落ちていたわけではなさそうですが、 朝で時間もないのでサーバごと再起動、それでもWebページが見えないので Apacheを再起動したら復活したようです。

>(1) char=16bit　/ short=16bit / int=16bit / long=32bit > C 言語仕様書 ISO/IEC 9899:1999 6.5.3.4 が sizeof(char)==1 を要求しているので > sizeof(char)==1 / sizeof(short)==1 / sizeof(int)==1 / sizeof(long)==2 となるとCHAR_BITが16で、malloc(1)で取れるのは16ビットで、となりますかね。 マイコンだと、UCS2までcharで使えてべんり! とはきっとならずに、 8bit単位で読み書きする必要があるたびにビット演算、となるのですかね。 お疲れ様です。

> ヒープとスタックが同じ方向に伸びようが無問題、という気はしますが。 御意。 ヒープとスタックが逆向きに伸びる＝残り RAM を最大限に利用可能、ってのはシングルタスクシングルスレッド限定の話。今どきはマイコンでもマルチスレッドマルチタスクを使う関係でスタック領域も事前に確保した固定長ですから。 ---- 世の中に x86 系が普及した（普及しすぎた）関係で x86 と違う仕様の CPU はみなゲテモノ扱いされちゃってるのが PC 業界の常識となっちゃっています。でもマイコン業界だとその辺のゲテモノがいっぱい残っていますし面白いですよ。 最近オイラが使った例だと TI 社の C2000 系マイコンなんかまさにゲテモノです。もともとが 16bit な DSP を無理くり 32bit CPU 化したという代物で、そのため (1) char=16bit　/ short=16bit / int=16bit / long=32bit C 言語仕様書 ISO/IEC 9899:1999 6.5.3.4 が sizeof(char)==1 を要求しているので sizeof(char)==1 / sizeof(short)==1 / sizeof(int)==1 / sizeof(long)==2 (2) スタックは高いアドレスに進む 既存コードが char=8bit を前提に書かれていたりするので、移植の際にはアセンブラ出力の読解が必須だったりします。他人に任せられない（自分自身も信頼できない）という罠

>奇遇？ですがこんな記事も書いたことがあります。 >https://ja.stackoverflow.com/questions/61298/ >PA-RISC な hpux がウチの部内サーバとして今でも現役っス。 なるほど。確かに奇遇というか、さすがです。 ちょっと調べた範囲だと、HP-UXだからといってsbrkが逆に伸びるわけではなさそうですね。、 https://community.hpe.com/t5/operating-system-hp-ux/sbrk-value/td-p/4961203 | current sbrk value = 0x15A4E000 | Maximum sbrk value = 0x7A000000 どのみちスタックサイズに制限をかけるなら、ヒープとスタックが同じ方向に 伸びようが無問題、という気はしますが。

>intの10要素の配列を3つほど宣言し、先頭アドレスを表示させてみたところ、 >たしかに、あとから宣言したものほど、低いアドレスに置かれていますね… すみません、ここをよく読んでいなかったようですが、 ひとつの関数の中でのローカル変数がメモリ上にどんな順に並ぶかは、 スタックの伸長方向とは無関係で、コンパイラ次第です。 たとえばintが4バイトとして、int a, b, c;という宣言なら、12バイト分の 領域を確保すればよいだけで、a, b, cの順に何かをする必要はありません。

奇遇？ですがこんな記事も書いたことがあります。 https://ja.stackoverflow.com/questions/61298/ PA-RISC な hpux がウチの部内サーバとして今でも現役っス。

>Wikipediaを見てみたら、以下の記述がありました。 すみません、Wikipediaのリンクを貼り忘れてました。 https://ja.wikipedia.org/wiki/%E3%82%B9%E3%82%BF%E3%83%83%E3%82%AF

>intの10要素の配列を3つほど宣言し、先頭アドレスを表示させてみたところ、 >たしかに、あとから宣言したものほど、低いアドレスに置かれていますね… > (linux x86_64, gcc 14.2.1) >不思議…　なんでなのでしょう? これはCの問題でもOSの問題でもなく、CPUの問題です。 たいていのCPUにはサブルーチンコールのためのCALL命令があり、戻り先をスタックに 積みます。これは機械語レベルの命令なのですが、この時、スタックはアドレスが小さい方に 向けて伸びるCPUが多いと思います。たとえば、おっさんプログラマならだれでも知っている 大昔の8ビットCPU Z80(1976年発表)でも、CALLすると、スタックの先頭を指しているレジスタで あるSPの値は減ります。 http://www.yamamo10.jp/yamamoto/comp/Z80/instructions/index.php#CALL_RETURN スタックがどちら向きに伸びるのかは、どっちでもよいようなものではありますが、 限られたメモリの中でプログラムを書く場合、プログラマが管理する領域は上から下に、 スタックは下から上に伸ばすようにしていけば、最後までメモリを使い切れる、という 事情はあったのではないかと思います。 今のCPU/言語でも、ポインタ完全制覇のFig2-3にあるように、malloc()で伸びる領域と スタックの領域の間には広大な空間があるわけです。 Wikipediaを見てみたら、以下の記述がありました。 | 昔のコンピュータで、ヒープ領域をアドレスの小さいほうから大きいほうへ伸ばし、 | スタックを大きいほうから小さいほうへ伸ばす（そのようにすると、メモリが足りない場合は | どちらを伸ばす余裕もなく、完全にメモリを使い切って計算続行不可能となる）という | 設計にした名残りから、アドレスの大きいほうから小さいほうへ伸びるものが多いが、 | PA-RISCは逆である。 逆のものもあるようですね。 もっとも、Cの場合、スタックを「アドレスの小さい方へ」伸ばすようにした結果、 バッファオーバーフロー脆弱性がずいぶんと狙いやすくなった、という実害が出ていますが……

どうも、おひさしぶりです。 >す～～～んごく細かい話で恐縮なのですが、同書 List 2-2(p.98)の45行目でmalloc()して >いますが、free()は要らないでしょうか?(まぁ、4bytesくらい、リブート迄放っておきま >しょう、でもよいかもしれませんが) List 2-2は、Cがメモリをどう使うのかを示すためのテストプログラムで、 まったくもって実用を想定したものではないので、free()はしていません。 free()しなかった場合どうなるかというと、プロセスが終了した時点で解放されます (リブートまで待つ必要はないです)。このプログラムの場合、どのみちすぐに終わるので、 free()してもしなくても同じことですね。

>たびたび細かい話をもうしわけありません。(件名、変えて投稿します) > >同書では、図時する場合、アドレスが増える方向は、多くの場合図の下方になっていると思います(例えば、Fig. 1-6)。そして、配列に関しても、Fig. 1-8では、array[]の添え字が増えるのは下方に向かって、になっています。 > >ところが、Fig. 2-7では、スタックの伸長方向の矢印は、上方に向かって書かれています。 >また、Fig. 2-9 では、hoge[]の添え字が増えるのは、下方に向かって、なのですが、やはり伸長方向の矢印は上向きになっています。 > >これは、「スタックは、番地が減る方向に利用範囲を広げていく」という事なのでしょうか? >積む、というイメージからは、番地が増える方向に利用範囲を広げていくように感じたのですが…(ある領域に固定長の配列をひとまとめに確保する、という場合でも、それは、番地の低い側に?) > >あ、いや、実験してみればよいのですね…　試してみます。 お騒がせして申し訳ありません。 intの10要素の配列を3つほど宣言し、先頭アドレスを表示させてみたところ、たしかに、あとから宣言したものほど、低いアドレスに置かれていますね… (linux x86_64, gcc 14.2.1) 不思議…　なんでなのでしょう?

たびたび細かい話をもうしわけありません。(件名、変えて投稿します) 同書では、図時する場合、アドレスが増える方向は、多くの場合図の下方になっていると思います(例えば、Fig. 1-6)。そして、配列に関しても、Fig. 1-8では、array[]の添え字が増えるのは下方に向かって、になっています。 ところが、Fig. 2-7では、スタックの伸長方向の矢印は、上方に向かって書かれています。 また、Fig. 2-9 では、hoge[]の添え字が増えるのは、下方に向かって、なのですが、やはり伸長方向の矢印は上向きになっています。 これは、「スタックは、番地が減る方向に利用範囲を広げていく」という事なのでしょうか? 積む、というイメージからは、番地が増える方向に利用範囲を広げていくように感じたのですが…(ある領域に固定長の配列をひとまとめに確保する、という場合でも、それは、番地の低い側に?) あ、いや、実験してみればよいのですね…　試してみます。

こんばんは。 す～～～んごく細かい話で恐縮なのですが、同書 List 2-2(p.98)の45行目でmalloc()していますが、free()は要らないでしょうか?(まぁ、4bytesくらい、リブート迄放っておきましょう、でもよいかもしれませんが) p.116では「…使う側にfree()の手間を押し付けることになります。」とも書かれているので… (すみません、昨日から同書を最初から読み直して勉強し直しているもので… 昔のBBS投稿を読み返したところ何年か前に「かずちゃん」というハンドル名で投稿していたようです)

こんにちは。ご指摘ありがとうございます。 >正誤表に、「p.240 Lis4-5 read_slogan.cの25行目」とありますが、p.241では? p.241ですね。修正いたしました。 >因みに、正誤表のこの箇所以降殆ど、"List"が"Lis"になってしまっているようです。 こちらも併せて修正いたしました。 ポカが多く申し訳ありません。

こんにちは。 正誤表に、「p.240 Lis4-5 read_slogan.cの25行目」とありますが、p.241では? 因みに、正誤表のこの箇所以降殆ど、"List"が"Lis"になってしまっているようです。 (初版第1刷所有者)

>正しく見えているようですよ ですね。ありがとうございます。 >更新直後状態から Web UA で証明書の有効期限がちゃんと変わっていましたし。 言われてみれば当たり前ですがそういえばそれを確認していませんでした f(^^:

正しく見えているようですよ 更新直後状態から Web UA で証明書の有効期限がちゃんと変わっていましたし。

本日、kmaebashi.comのSSL証明書を更新しました。 今のところ問題なく動いているように見えますが、月末が旧証明書の期限切れなので、 それを過ぎないと本当に成功したかどうかはわかりませんかねえ。

Tomcatが落ちてもsystemdが再起動してくれるように設定しました。 kill -9しても生き返ったので大丈夫っぽいです。 メモ。 /etc/systemd/system/tomcat.service の設定は以下の通り。 Restart=alwaysがミソですが、最初設定した時いい加減なWeb記事をうのみにして 設定してしまったので、それだけではすまなかった…… <ここから><ここから><ここから><ここから> [Unit] Description=Apache Tomcat 10 After=network.target [Service] User=tomcat Group=tomcat Type=forking PIDFile=/opt/apache-tomcat-10.1.13/tomcat.pid Restart=always ExecStart=/opt/apache-tomcat-10.1.13/bin/startup.sh ExecStop=/opt/apache-tomcat-10.1.13/bin/shutdown.sh [Install] WantedBy=multi-user.target

>OSが再起動したらTomcatも起動するように設定しているはずですが、 >もしかしてそこが動いていないのかも? ためしに再起動しましたがちゃんと動いていますねえ。