K.Maebashi's BBS

症状的には 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も起動するように設定しているはずですが、 >もしかしてそこが動いていないのかも? ためしに再起動しましたがちゃんと動いていますねえ。

また朝の6:26にdnfによるupdateが走って、この掲示板が停止していました。 ちょっと頻度が高いので、まじめに対策を考えます…… OSが再起動したらTomcatも起動するように設定しているはずですが、 もしかしてそこが動いていないのかも?

>『これから学ぶJavaScript』という入門本 >著者 WINGS プロジェクト 齊藤 新三　著/山田 祥寛　監修 >https://book.impress.co.jp/books/1117101136 > >（Kindle Unlimitedでサブスクで読めました） > >に「インタプリタは機械語に翻訳しながら実行する」と書いてありました 情報ありがとうございます。 最近この手の入門書は買ってまで読みませんが、ネット上にこれだけこの間違いが あふれている以上、紙書籍にも書いてあるのでしょうね。 しかし、著者の方は存じ上げませんが、山田祥寛さんといえばかなり有名な ライターだと思うのですが、その方が監修してこの有様なんですかねえ。 >>一方、もうひとつは、 >>ソースコードを実行する際にその場でマシン語に変換する方法で、 >>インタプリタといい、この方式をとる言語をインタプリタ言語といいます。 >>こちらの言語は、見た目にはソースコードを直接実行しているように見えますが、 >>実は実行時に変換されています JavaScriptでもJITコンパイラはあるので、実行時に機械語に変換されるという ケースももちろんあるのでしょうが、それをインタプリタというのは明確に誤りですね。

『これから学ぶJavaScript』という入門本 著者 WINGS プロジェクト 齊藤 新三　著/山田 祥寛　監修 https://book.impress.co.jp/books/1117101136 （Kindle Unlimitedでサブスクで読めました） に「インタプリタは機械語に翻訳しながら実行する」と書いてありました >一方、もうひとつは、 >ソースコードを実行する際にその場でマシン語に変換する方法で、 >インタプリタといい、この方式をとる言語をインタプリタ言語といいます。 >こちらの言語は、見た目にはソースコードを直接実行しているように見えますが、 >実は実行時に変換されています 前橋さんがブログに書いていましたが インタープリタは「翻訳」しない https://kmaebashi.hatenablog.com/entry/20160705/p1 未だに入門書には、 インタプリタはマシン語に変換しながら実行すると説明があるようです。

おそらく今朝06:10頃に動いたアップデートが原因だと思うのですが、 この掲示板が停止していました。Tomcatを再起動したところ、直ったようです。

こんにちは。 >簡潔になるのは理解できるんですけど、functionを使うのをやめて全部アロー関数に >したほうがいいんですかね？ 私はといえば、たとえばこちらでもfunctionを使っていますし、 https://kmaebashi.com/programmer/beginner/javascriptintro.html この掲示板とか(まあここのソースはたいがい古いですが)、その他JavaScriptを 書く時も基本的にfunctionです。下記に書いた通りアロー関数は 『forEach()とかmap()とかで気楽に使うもの』という認識なので、 https://kmaebashi.com/programmer/beginner/javascriptoop.html 名前を付けられるような関数はちゃんと名前を付けるべき、と思っています。 かつてTwitterにはこんなことを書いていましたが、 https://x.com/kmaebashi/status/1130497188729987072 今検索してみると、やはりこれについては悩んでいる人がいて、 https://zenn.dev/rgbkids/books/0b75c912d8ac70/viewer/e0fd3e このあたりを見てみると、各種コーディング規約でもfunctionを勧めているのが 多いようですね。

最近アロー関数という書き方を知ったんですけど、古い書き方をずっと使っていたものからするととっつきにくい気がします。 function a() { console.log("hello, world!") } この関数をアロー関数に変換すると、以下のようになります。 JavaScript const a = () => console.log("hello, world!"); 簡潔になるのは理解できるんですけど、functionを使うのをやめて全部アロー関数にしたほうがいいんですかね？

>と書いてあるのですが、コピペして直し忘れているように見えるので修正したほうがいいと思いました。 うわ、ご指摘ありがとうございます。 直しました…… 気付かないものですねえ。

「C言語 ポインタ完全制覇(第2版)」ダウンロード https://kmaebashi.com/seiha2/download.html このページに「このページは、拙著「Webサーバを作りながら学ぶ 基礎からのWebアプリケーション開発入門」の掲載ソースコードのダウンロードページです。」 と書いてあるのですが、コピペして直し忘れているように見えるので修正したほうがいいと思いました。

>ちょっと確認し、連休中に対応します。 Java17まではShift-JISが標準だったのが、21でUTF-8になっていることを確認のうえ、 UTF-8版のソースを配置しました。ご指摘ありがとうございました。 この本より後に出したポインタ完全制覇改訂版では最初からUTF-8を配布してますね。 Javaが、ごく最近までShift-JISを標準にしていたのが意外なくらいの話で。

>Shift JIS（CP932）だとデフォルトでVSCodeもEclipseも文字化けしたので、 >UTF-8版のソースコードも配布したほうが親切かなと思います。 ご指摘ありがとうございます。なるほど、そういう時代ですね。 javacのデフォルトエンコーディングは長いことShift-JISでしたが、 今調べたらJava18からUTF-8になってるっぽい? ちょっと確認し、連休中に対応します。