K.Maebashi's BBS

>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になってるっぽい? ちょっと確認し、連休中に対応します。

Shift JIS（CP932）だとデフォルトでVSCodeもEclipseも文字化けしたので、UTF-8版のソースコードも配布したほうが親切かなと思います。Windows PowerShellで一括変換する方法もありました。自分はそうしましたが、できない人もいると思うので。 複数個のファイルの文字コードをShift_JISからutf-8(BOMなし)に変換する https://nagaragawa-r.com/convert-character-code-shift_jis-to-utf-8-without-bom/

こんにちは。しばらくここを見てなかったようで返信が遅れました。 >togetterに配列の添字演算子はポインタ演算のシンタックスシュガーだよ、 >という記事が載っていました。 >意外と知られていないみたいです。 >https://togetter.com/li/2393030 紹介ありがとうございます。まとめの中にもポインタ完全制覇は出てきますが、 まだまだ普及が足りてないですかねえ。

togetterに配列の添字演算子はポインタ演算のシンタックスシュガーだよ、という記事が載っていました。 意外と知られていないみたいです。 https://togetter.com/li/2393030

>C の場合 >変数定義で要素数を書かない場合（上記 static int a[]; が該当）には当該変数は >不完全型な仮定義 (tentative definition) になる・・・と言いたいところなんですが > static がある場合には仮定義にならず一発定義になります。 確認しました。ここについてはこれですかね。 | 6.9.2 外部オブジェクト定義 … | オブジェクトに対する識別子の宣言が仮定義であり，内部結合をもつ場合， | その宣言の型は不完全型であってはならない。 これを普通に読むと、 static int a[]; はそれ自体でコンパイルエラーになりそうなものですが (まあ実際、役に立たないと思いますし)、 | 大きさの分からない配列型は，不完全型とする。その型は，それ以降のその型の | 識別子の宣言（内部結合又は外部結合をもつ）で大きさを指定することによって， | 完全となる。 こっちでは(内部結合でも)それ以降の宣言で大きさを指定すればよい、 とあるようで、これがどういう時に有効なのか、読み解けていません…

いつもありがとうございます。 >C の場合 >変数定義で要素数を書かない場合（上記 static int a[]; が該当）には当該変数は >不完全型な仮定義 (tentative definition) になる・・・と言いたいところなんですが > static がある場合には仮定義にならず一発定義になります。 >また、要素数についてはコンテキスト次第で解釈が変わってよいところです。 >とあるコンテキストではこれを int a[1]; と読んでよいことになっています。 >別のコンテキストではこれを不完全型と読んでよい（要素数未知）ことになっています。 この週末は出かけますのでこのあたり帰ってきたら確認します……

この辺 C と C++ で微妙に仕様が違うところピンポイントで踏み抜いているのでいろいろわけわからんことになっています。今この瞬間には C 言語仕様書 JIS X 3010 ならびに C++ 言語仕様書 JIS X 3014 にアクセスできないので記憶とコンパイラの挙動だけで話をします。 サンプルソース tentative.c ないしは tentative.cpp static int a[]; static int a[4]; unsigned long f() { return sizeof a; } C の場合 変数定義で要素数を書かない場合（上記 static int a[]; が該当）には当該変数は不完全型な仮定義 (tentative definition) になる・・・と言いたいところなんですが static がある場合には仮定義にならず一発定義になります。また、要素数についてはコンテキスト次第で解釈が変わってよいところです。とあるコンテキストではこれを int a[1]; と読んでよいことになっています。別のコンテキストではこれを不完全型と読んでよい（要素数未知）ことになっています。詳細は言語仕様書を読まないと出てきません（覚えていません）。 cygwin64 にて $ gcc --version gcc (GCC) 11.4.0 // 以下略 $ gcc -W -Wall -pedantic -O -S tentative.c tentative.c:1:12: error: array size missing in 'a' 1 | static int a[]; | ^ tentative.c:2:12: error: conflicting types for 'a'; have 'int[4]' 2 | static int a[4]; | ^ tentative.c:1:12: note: previous declaration of 'a' with type 'int[1]' 1 | static int a[]; | ^ tentative.c:1:12: warning: 'a' defined but not used [-Wunused-variable] $ ということで gcc-11.4.0 は先の例を static int a[1]; と読んでいます。本当にそう読んだのかアセンブラコードで確認したいところですが、残念ながらコンパイルエラーになっているので確かめられません。 C++ の場合 C にあった仮定義がなくなっている関係で int a[]; は個数不定な「変数定義」になります。なのでこの時点でコンパイルエラー。更に ODR (one definition rule) も適用され int a[4]; と矛盾しここでもエラーになります。 $ g++ -W -Wall -pedantic -O -S tentative.cpp tentative.cpp:1:12: error: storage size of 'a' isn't known 1 | static int a[]; | ^ $ あるいは Visual Studio 2019 の VC++ だと D:\work\tmp>cl -W4 -Ox -c tentative.c Microsoft(R) C/C++ Optimizing Compiler Version 19.29.30154 for x64 Copyright (C) Microsoft Corporation. All rights reserved. tentative.c tentative.c(1): error C2133: 'a': サイズが不明です。 D:\work\tmp>cl -W4 -Ox -c tentative.cpp Microsoft(R) C/C++ Optimizing Compiler Version 19.29.30154 for x64 Copyright (C) Microsoft Corporation. All rights reserved. tentative.cpp tentative.cpp(1): error C2133: 'a': サイズが不明です。 tentative.cpp(2): error C2086: 'int a[]': 再定義されました。 tentative.cpp(1): note: 'a' の宣言を確認してください tentative.cpp(4): error C2070: 'int []': sizeof オペランドが正しくありません。 というわけで不完全型な変数定義になる static int a[]; は書いちゃダメ、コンパイラ次第で挙動が違う、でしょう。まあコンパイルエラーになってくれるので、実行するまでわからないという最恐な事態には陥らなくて済みそうです。

>>OS : Windows10 Enterprise (ver 22H2) >>コンパイラ: gcc　6.3.0 > >ちょっと調べてMinGWはgcc 6.3.0って古すぎないかという記事を見かけたので、 >https://stackoverflow.com/questions/68360901/why-is-the-latest-mingw-gcc-version-6-3-0 > >MinGWなら6.3.0があるのかな、とosdn.netからmingw-get.exeとやらを入手して >6.3.0をインストールしようとしたのですがないと言われて >7.3.0-1を(むりやり)動かしたら再現しました。正直驚きました。 > >>#include <stdio.h> >> >>static int a[]; >> >>int main() >>{ >> >> return 0; >>} > >これだと配列aのサイズが決まっていないわけで、ではコンパイラはaのサイズを >いくつだと思っているのか確認しようと > > printf("sizeof a..%d\n", sizeof(a)); > >とやってみると、 >invalid application of 'sizeof' to incomplete type 'int[]' > >と言われます。aがincomplete type(不完全型)だと言っています。 > >これについては規格でも「6.2.5 型」のところで > >| 大きさの分からない配列型は，不完全型とする。その型は，それ以降のその型の >| 識別子の宣言（内部結合又は外部結合をもつ）で大きさを指定することによって， >| 完全となる。 > >という記載があるので、以下のようにint a[10];を追加したら、 >gccの9.4.0でもコンパイルが通って、「sizeof a..40」と表示されました。 > >#include <stdio.h> > >static int a[]; > >static int a[10]; > >int main() >{ > printf("sizeof a..%d\n", sizeof(a)); > return 0; >} > >それにしても、staticなのにこの.c内でサイズ指定して完全型にならないのなら、 >やっぱりコンパイルを通してはダメだと思うのですが…… >なので最近のgccではエラーにしているのだと思います。 >私も勉強になりました。ありがとうございました。 ご回答ありがとうございます。 私のgccそんなに古かったとは… 環境構築の際に、どこかの参考サイトの書いてあるがままにインストールしていました。(反省します) gccを13.2.0に更新して試してみたところ、前橋様と同じ挙動になりました。 こちらこそ変な質問に丁寧にご対応頂きありがとうございました。

>OS : Windows10 Enterprise (ver 22H2) >コンパイラ: gcc　6.3.0 ちょっと調べてMinGWはgcc 6.3.0って古すぎないかという記事を見かけたので、 https://stackoverflow.com/questions/68360901/why-is-the-latest-mingw-gcc-version-6-3-0 MinGWなら6.3.0があるのかな、とosdn.netからmingw-get.exeとやらを入手して 6.3.0をインストールしようとしたのですがないと言われて 7.3.0-1を(むりやり)動かしたら再現しました。正直驚きました。 >#include <stdio.h> > >static int a[]; > >int main() >{ > > return 0; >} これだと配列aのサイズが決まっていないわけで、ではコンパイラはaのサイズを いくつだと思っているのか確認しようと printf("sizeof a..%d\n", sizeof(a)); とやってみると、 invalid application of 'sizeof' to incomplete type 'int[]' と言われます。aがincomplete type(不完全型)だと言っています。 これについては規格でも「6.2.5 型」のところで | 大きさの分からない配列型は，不完全型とする。その型は，それ以降のその型の | 識別子の宣言（内部結合又は外部結合をもつ）で大きさを指定することによって， | 完全となる。 という記載があるので、以下のようにint a[10];を追加したら、 gccの9.4.0でもコンパイルが通って、「sizeof a..40」と表示されました。 #include <stdio.h> static int a[]; static int a[10]; int main() { printf("sizeof a..%d\n", sizeof(a)); return 0; } それにしても、staticなのにこの.c内でサイズ指定して完全型にならないのなら、 やっぱりコンパイルを通してはダメだと思うのですが…… なので最近のgccではエラーにしているのだと思います。 私も勉強になりました。ありがとうございました。