K.Maebashi's BBS

修正済み確認しました。 イヤンな spam (?) 投稿が無い分、今のトラフィックで十分幸せになれそうです。っていうか spam 投稿フィルタがちゃんと機能しているのでしょうか？ 件名が Re:Re:Re のおじさんになるのは仕様のようですね。

>top page 中 google 検索ボタンのリンクが http:// なので Chrome 120.0.6099.63 で >サイト情報を確認すると「完全には保護されていません」の旨表示されます。 ありがとうございます。Firefoxでも警告が出ました。修正いたしました。 せっかく掲示板を作り直したのに誰も書きこんでくれなくて悲しくなっていたので、 その点でもありがとうございました……

今頃気づいた・・・ top page 中 google 検索ボタンのリンクが http:// なので Chrome 120.0.6099.63 でサイト情報を確認すると「完全には保護されていません」の旨表示されます。掲示板のページまで来るとボタンが無いので「この接続は保護されています」になる模様。 証明書の確認は MITM 串が入っている関係で会社からでは不可能でした。

移転前の掲示板は2005年頃にPHPで作ったものでしたが、今回、共用のレンタル サーバからVPSに乗り換えたので、言語も自由に選べるので、PHP版は捨てて Java + Spring boot + PostgreSQLで作り直しました。 拡張子は.phpになっていますが、これは以前の掲示板へのリンクを生かすためで、 中身はPHPではありません。 仕様もところどころ変わっています。投稿の手数がちょっと減りました。 cssがキャッシュに残っていると中途半端に効いて表示が崩れるので、 Ctrl + F5とかで強制リロードしてください。 過疎掲示板ですが、今後ともよろしくお願いいたします。

>この掲示板のデータを移転先サーバに移行します。 >この後に何を書いても、移行対象になりませんのでご注意ください。 移行終了しました(と、新掲示板から書き込む)。

この掲示板のデータを移転先サーバに移行します。 この後に何を書いても、移行対象になりませんのでご注意ください。

トップページにも書きましたが、本Webサイトを置いているレンタルサーバの業者が 事業を撤退するとのことで、近々サーバを移転します。 ドメインは変わらないので閲覧者の皆様に特に影響はないと思いますが、 DNSの切り替えがうまくいかなかったり、当方でサーバを再起動したりで 一時的に不安点になる可能性はあります。 あしからずご了承くださいませ。 移転予定日…10/7～10/9の三連休のどこか この掲示板は、過去投稿のデータを含めて新サーバに移行する予定です。 直前に「今から移行する」旨書き込みますので、その書き込みまでの投稿は 新サーバに移ります。 (……のつもりですが、何しろ私のやることなので、とんでもないポカを やらかす可能性もあります) よろしくお願いいたします。

ご返事ありがとうございます。 >できない理由は特にないので、普通にできます。以下、掛け算九九の表をmalloc()で >確保するプログラムです(これは「普通」には見えない、というならまあもっともですが)。 サンプルコードまで示して回答していただきまして大変感激です。ありがとうございます。 私が試したときは『int (*alloc99(void))[9]』の部分を『(int(*)[9]) alloc99(void)』のように書いてしまっていました(キャストの構文と混同していたようです)。確かにお見せいただいたコードなら「配列へのポインタを関数」の宣言になっていますね。 >ただ、 > >>"func()[0].hoge"みたいなことがやってみたかったのですが、C言語では無理なのでしょうか。 > >上記のやってみたいことからすると、そもそもやりたいことは「配列へのポインタ」を >返すことではないようにも思えます。"func()[0].hoge"と書きたいのなら、やりたいことは、 >「構造体へのポインタ」を返すことではないでしょうか。 これはまったくご指摘の通りです。 投稿してから気づいたのですが、訂正前に回答が来てしまってお恥ずかしい限りです……

>C言語では、「配列へのポインタ」は関数の戻り値にはできないのでしょうか？ >VisualC++でやってみたのですが、無理でした。 できない理由は特にないので、普通にできます。以下、掛け算九九の表をmalloc()で 確保するプログラムです(これは「普通」には見えない、というならまあもっともですが)。 #include <stdio.h> #include <stdlib.h> int (*alloc99(void))[9] { return malloc(sizeof(int) * 81); } int main(void) { int (*array99)[9]; int i, j; array99 = alloc99(); for (i = 1; i < 10; i++) { for (j = 1; j < 10; j++) { array99[i - 1][j - 1] = i * j; } } for (i = 1; i < 10; i++) { for (j = 1; j < 10; j++) { printf("\t%d", array99[i - 1][j - 1]); } printf("\n"); } } ただ、 >"func()[0].hoge"みたいなことがやってみたかったのですが、C言語では無理なのでしょうか。 上記のやってみたいことからすると、そもそもやりたいことは「配列へのポインタ」を 返すことではないようにも思えます。"func()[0].hoge"と書きたいのなら、やりたいことは、 「構造体へのポインタ」を返すことではないでしょうか。

C言語では、「配列へのポインタ」は関数の戻り値にはできないのでしょうか？ VisualC++でやってみたのですが、無理でした。 "func()[0].hoge"みたいなことがやってみたかったのですが、C言語では無理なのでしょうか。

ご返信いただきまして、ありがとうございます。すっきり理解することができました。 ざっと読んでは細かく読むというのを繰り返している状況です。 また疑問点があった際には質問させていただければと思います。 今後ともよろしくお願いいたします。 >はじめまして。 > >>学生時代に逃げ出したポインタへ改めて向き合おうと思い、ポインタ完全制覇を読ませていただいております。 >>読み進める中で、こちらの投稿と同じところでつまずいてしまったので質問させていただきます。 >>*pという記法の場合、p+1要素のサイズという足し算が各繰り返しごとに行われていると解釈したのですが、 >>掛け算はどの段階で行われているのでしょうか。 > >まず、array[i]の記法の場合、array[i]を使うごとに「array + (i * 1要素のサイズ)」に >相当するアドレス計算を行う必要があります。 >*pの記法の場合、ループの1回のくり返しの中ではpは動かないので、上記のような >アドレス計算を何度も行う必要はない(だから最適化をしないコンパイラなら速くなる)、 >というのが該当の記述の趣旨だったのですが、 > >p.75の該当の記述は以下のようになっていて、 >「*pがループの中に何度出現しても、掛け算と足し算はループの終わりの >1回だけで済みます。」 >*pの記法の場合、各ループの末で行うのはp++であって、毎回ひとつずつ進めるのであれば、 >確かに掛け算は不要です。 > >・array[i]記法では、ループ内にarray[i]が何度も出てきたら、その数だけ掛け算と足し算を行う。 >・*p記法では、*pが何度出てきても、そういう計算は1回でよい。 >ということを言いたかったのですが、「そういう計算」の中身が違いますね。 >本の記述が誤りだと思います。 > >22年以上前の初版本からこの記述はあるのですが、この誤りは見つかっていませんでした。 >ご指摘ありがとうございました。正誤表に入れさせていただきます。

はじめまして。 >学生時代に逃げ出したポインタへ改めて向き合おうと思い、ポインタ完全制覇を読ませていただいております。 >読み進める中で、こちらの投稿と同じところでつまずいてしまったので質問させていただきます。 >*pという記法の場合、p+1要素のサイズという足し算が各繰り返しごとに行われていると解釈したのですが、 >掛け算はどの段階で行われているのでしょうか。 まず、array[i]の記法の場合、array[i]を使うごとに「array + (i * 1要素のサイズ)」に 相当するアドレス計算を行う必要があります。 *pの記法の場合、ループの1回のくり返しの中ではpは動かないので、上記のような アドレス計算を何度も行う必要はない(だから最適化をしないコンパイラなら速くなる)、 というのが該当の記述の趣旨だったのですが、 p.75の該当の記述は以下のようになっていて、 「*pがループの中に何度出現しても、掛け算と足し算はループの終わりの 1回だけで済みます。」 *pの記法の場合、各ループの末で行うのはp++であって、毎回ひとつずつ進めるのであれば、 確かに掛け算は不要です。 ・array[i]記法では、ループ内にarray[i]が何度も出てきたら、その数だけ掛け算と足し算を行う。 ・*p記法では、*pが何度出てきても、そういう計算は1回でよい。 ということを言いたかったのですが、「そういう計算」の中身が違いますね。 本の記述が誤りだと思います。 22年以上前の初版本からこの記述はあるのですが、この誤りは見つかっていませんでした。 ご指摘ありがとうございました。正誤表に入れさせていただきます。

学生時代に逃げ出したポインタへ改めて向き合おうと思い、ポインタ完全制覇を読ませていただいております。 読み進める中で、こちらの投稿と同じところでつまずいてしまったので質問させていただきます。 *pという記法の場合、p+1要素のサイズという足し算が各繰り返しごとに行われていると解釈したのですが、掛け算はどの段階で行われているのでしょうか。 ご回答よろしくお願いします。 >はじめまして。読んでいただきありがとうございます。 > >>array[i]は、ループ中に出現するたびごとに「array + (i * 1要素のサイズ)」に相当する >>アドレス計算を行うというのは理解できますが、*pでも「p + (p++ごとに1要素のサイズ)」 >>に相当するアドレス計算を行っているように思えます。「掛け算と足し算はループの終わり >>の1回だけ」という意味をご教示いただけるとありがたいです。 > >「ループの終わりの1回だけ」というのは、たとえばループが100回回ったとして、 >各繰り返しの最後に1回、という意味です。つまり、100回ループが回れば、 >「p + 1要素のサイズ」という計算は100回は行います。 >ただし、ループの中に、array[i]が5回出てくるとすれば、最適化をろくにやらない >コンパイラなら、100回ループが回った時に「array + (i * 1要素のサイズ)」という計算は >500回行われます。それが100回で済むなら、*pの方が高速になるでしょう。 >コメントで「array[i]は、何度も登場する」と書いてあるのはそういう意図です。 > >これで回答になっていますでしょうか? > >

>これですが、規格書(JIS X3010:2003)の「6.7.8 初期化」に以下の記載があります。 ご指摘ありがとうございます。このような書き方が可能なことを知りませんでした…。 勉強になりました。 良く調べてからご連絡すべきでした。失礼しました。 ご対応もありがとうございます。

お待たせしました。 >「C言語 ポインタ完全制覇」P363 List 6-4 designated_initializer.c の 20 行目は以下ではないでしょうか。 >　　誤　Hoge hoge = {.b = 3, .c = 5, {[3] = 10, 11, 12}}; >　　正　Hoge hoge = {.b = 3, .c = 5, .array = {[3] = 10, 11, 12}}; これですが、規格書(JIS X3010:2003)の「6.7.8 初期化」に以下の記載があります。 >指示がない場合，現オブジェクト中の部分オブジェクトを，現オブジェクトの型に従う順序で >初期化する。すなわち，配列要素は添字の昇順で初期化し，構造体メンバは宣言の順で初期化し， >共用体では最初の名前付きメンバを初期化する(127)。 >一方，指示が存在する場合，それに続く初期化子を使って要素指示子が示す部分オブジェクトを >初期化する。そして要素指示子で示される部分オブジェクトの次の部分オブジェクトから >順に初期化を続ける(128)。 「要素指示子で示される部分オブジェクトの次の部分オブジェクトから順に初期化を続ける」 とあるので、書き方としては正当だと思います。gccに-std=c99 -pedanticオプションを付けて 警告もなく実行できました。 ただ、説明不足なのは否めませんので、補足を上げようと思います。 ご指摘ありがとうございました。

>「C言語 ポインタ完全制覇」P363 List 6-4 designated_initializer.c の 20 行目は以下ではないでしょうか。 >　　誤　Hoge hoge = {.b = 3, .c = 5, {[3] = 10, 11, 12}}; >　　正　Hoge hoge = {.b = 3, .c = 5, .array = {[3] = 10, 11, 12}}; ご報告ありがとうございます。 すみません、この週末は用事がありまして、対応は月曜とさせてください。

「C言語 ポインタ完全制覇」P363 List 6-4 designated_initializer.c の 20 行目は以下ではないでしょうか。 　　誤　Hoge hoge = {.b = 3, .c = 5, {[3] = 10, 11, 12}}; 　　正　Hoge hoge = {.b = 3, .c = 5, .array = {[3] = 10, 11, 12}};

>64才のに元ソフト系エンジニアです。 はじめまして。拙著を読んでいただきありがとうございます。 >やっと時間が出来たので、やはり買ったままになっていた前橋さんの本(2009年の初版)を >読み始めました。ネットに公開されている前橋さんのコードをエディタで関数やデータ型を >探したり眺めたりしながら、前橋さんの本を読み進めています。 この本は日本では初版しかないのですが、どういうわけか中国で評判が良いようで(中国語版が出ています)、中国人の中学生から(英語で)質問メールをもらったりしました。返信の英作文には苦労しましたが、読まれている実感があって嬉しいものです。 Diksamは、書籍出版の後もごそごそいじっていたのですが、追加機能分が結局形にならず放置状態になっているのが心苦しく思っています。 私も、定年退職でもしましたら、趣味プログラムに没頭したいものだと思っております。 >「もうひとつのプログラミング言語を作る」のような次回作を期待しています。 規模からすればDiksamよりはるかに小さいですが、静的型付けのバイトコード実行型言語として、Samplanというおもちゃ言語を作っています。 https://kmaebashi.hatenablog.com/entry/2021/10/31/211618 実用性はまったくないと思いますが、yaccに頼らず手書きの再帰下降パーサで作った言語です。よろしければこちらもどうぞ。

64才のに元ソフト系エンジニアです。 在職中はマルチメディア関係のシステムの研究、開発、市場開発、プロジェクト管理などをやっていました。コンパイラには学生時代から関心があり、AhoとUllumanの本を買ったりしましたが、眺めるだけで読み進めることなく定年を迎えました。 やっと時間が出来たので、やはり買ったままになっていた前橋さんの本(2009年の初版)を読み始めました。ネットに公開されている前橋さんのコードをエディタで関数やデータ型を探したり眺めたりしながら、前橋さんの本を読み進めています。 Cは学生時代から30才くらいまでコードを書いていたので分かっているつもりでしたが、結構怪しくて本を参照しながらですが。 やっとcrowbarが終わって、これからDiksamです。 前橋さんの巧妙な語り口に助けられ、補足なども楽しみながら、昔に戻って楽しい時間を過ごしています。Pascalのgotoにラベルが書けない理由、ヘッダファイルをパブリックとプライベートに分ける手法、不完全型の技法などはオールドプログラマには新鮮でした。 「もうひとつのプログラミング言語を作る」のような次回作を期待しています。 それまでになんとかDiksamも読了しておきますので。

返信が大変遅れまして申し訳ありません。 丁寧にご回答頂きましてありがとうございます。 >まず、「入力時のサニタイズ」と「入力時のバリデーション」は違う話ですよね。 >リンク先の記事を書いている大垣さんも、「入力時のサニタイズ」は擁護していないと >思います。 そうですよね。勝手に改変したものをそのまま後に渡しているのは。 >「入力時のバリデーション」は、変な入力は入力の時点でエラーにして後ろに流さない >わけですが、これは別段セキュリティ関係なく、ユーザの入力ミスに備えてやるべき >ことですし、その要件はアプリケーションの仕様に依存します。 >もちろん、電話番号欄にシングルクォートとか入力されたらエラーにすればよいですし、 >そうすることが結果的にセキュリティに資することもあると思います。 入力時のバリデーションはあくまでも「仕様の問題」ということですね。 >入力時バリデーションは、 >・そもそも要件としてバリデーションできないケースが(かなり)ある。 >・入力から、DBとか、再度画面に表示されるところまでには、プログラム的に >　長い経路があり、「セキュリティのために」狙ってバリデーションするのは >　実際には困難。 > >という問題があります。そこで、入力時バリデーションはセキュリティ対策としては >「あてにできる」ものではない、と私は思います。 入力時バリデーションがセキュリティに有効なこともあるのはあくまで結果論ということですね。

>kmaebashiさんが『「サニタイズ言うなキャンペーン」について、私の解釈』や、 >著書でも述べられている、「SQLやHTML等で特別な意味を持つ文字列のエスケープは、 >入力時ではなくそれが外部に出力される直前に行うべき」という主張は納得できる >ものだと私も思います。 >ただ、以下リンク先のページを見ると、CWE-20等の国際的なセキュリティ標準でも >入力時のチェックを奨励しているように思えまして、ちょっと混乱しています。 >https://gihyo.jp/dev/serial/01/php-security/0045 >「ユーザーからの入力はどんな文字列でも扱えるべきだが、システム内の各階層では、 >メソッドの引数チェックなりをしっかりやるように」との意味合いなのでしょうか？ まず、「入力時のサニタイズ」と「入力時のバリデーション」は違う話ですよね。 入力時にサニタイズ(無害化)するということは、無害化したその入力を後ろに 流してしまうわけです。実際、当時のPHPのmagic quoteはそんな仕組みでした。 これはどう考えてもおかしいわけで、今はPHPのmagic quoteは廃止されましたし、 リンク先の記事を書いている大垣さんも、「入力時のサニタイズ」は擁護していないと 思います。 「入力時のバリデーション」は、変な入力は入力の時点でエラーにして後ろに流さない わけですが、これは別段セキュリティ関係なく、ユーザの入力ミスに備えてやるべき ことですし、その要件はアプリケーションの仕様に依存します。たとえばこの掲示板の 本文は、シングルクォートだろうがHTMLタグだろうが通さなければいけないでしょう。 もちろん、電話番号欄にシングルクォートとか入力されたらエラーにすればよいですし、 そうすることが結果的にセキュリティに資することもあると思います。 入力時バリデーションは、 ・そもそも要件としてバリデーションできないケースが(かなり)ある。 ・入力から、DBとか、再度画面に表示されるところまでには、プログラム的に 　長い経路があり、「セキュリティのために」狙ってバリデーションするのは 　実際には困難。 という問題があります。そこで、入力時バリデーションはセキュリティ対策としては 「あてにできる」ものではない、と私は思います。 徳丸浩さんの記事： もう入力値検証はセキュリティ対策として *あてにしない* ようにしよう https://tumblr.tokumaru.org/post/55393403591/%E3%82%82%E3%81%86%E5%85%A5%E5%8A%9B%E5%80%A4%E6%A4%9C%E8%A8%BC%E3%81%AF%E3%82%BB%E3%82%AD%E3%83%A5%E3%83%AA%E3%83%86%E3%82%A3%E5%AF%BE%E7%AD%96%E3%81%A8%E3%81%97%E3%81%A6-%E3%81%82%E3%81%A6%E3%81%AB%E3%81%97%E3%81%AA%E3%81%84-%E3%82%88%E3%81%86%E3%81%AB%E3%81%97%E3%82%88%E3%81%86 半面、入力バリデーション(と静的な型付け)で実際の攻撃を防げるケースもかなり あるとも言われてはいて、たとえばOWASPの Application Security Verification Standard 4.0には以下の記述があります。 https://owasp.org/www-pdf-archive/OWASP_Application_Security_Verification_Standard_4.0-en.pdf > Properly implemented input validation controls, using positive whitelisting > and strong data typing, can eliminate more than 90% of all injection attacks. > Length and range checks can reduce this further. ホワイトリストと静的型付けによる適切な入力バリデーションでインジェクション攻撃の 90%以上が防げるとあります。 大垣さんと徳丸さんとのこの手の議論は長くて、嫌気がさすほどですが(最終的に、 徳丸さんの方が、(おそらくは呆れ果てて)議論を放棄している)、 https://ockeghem.hatenablog.jp/entry/20111226/p1 https://tumblr.tokumaru.org/post/55587596019/%E5%8B%9D%E6%89%8B%E3%81%AB%E8%A7%A3%E8%AA%AC%E5%A4%A7%E5%9E%A3%E6%B5%81%E3%83%90%E3%83%AA%E3%83%87%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E5%85%A5%E9%96%80 入力時バリデーションが結果的にセキュリティ対策になることは徳丸さんは 一切否定していないので、どうもこの「議論」は食い違っているように私には見えます。 そもそも徳丸さんは、OWASP Japanアドバイザリーボードという立場の方なので、 OWASP含め、「国際的なセキュリティ標準」が何を言っているのか知らないわけはないですし。

kmaebashiさんが『「サニタイズ言うなキャンペーン」について、私の解釈』や、著書でも述べられている、「SQLやHTML等で特別な意味を持つ文字列のエスケープは、入力時ではなくそれが外部に出力される直前に行うべき」という主張は納得できるものだと私も思います。 ただ、以下リンク先のページを見ると、CWE-20等の国際的なセキュリティ標準でも入力時のチェックを奨励しているように思えまして、ちょっと混乱しています。 https://gihyo.jp/dev/serial/01/php-security/0045 「ユーザーからの入力はどんな文字列でも扱えるべきだが、システム内の各階層では、メソッドの引数チェックなりをしっかりやるように」との意味合いなのでしょうか？

書いてあったんですね。失礼しました。m(_ _)m

>読みました。 読んでいただきありがとうございます。 >この参照値という言葉は初出な気がするのですが、 以下のページで出ています。 http://kmaebashi.com/programmer/beginner/javascriptintro.html http://kmaebashi.com/programmer/beginner/array.html 検索経由とかでこのページから読み始める人もいるかもしれませんが、 >JavaScriptでは、オブジェクトは参照経由でアクセスします。 >関数もオブジェクトですから、参照で扱います。ここでは、alertとmyAlertは、 >どちらも同じ関数オブジェクトを「指して」います。 >つまり、alertやmyAlertが保持しているのは関数そのものに対する参照値です。 と書いていて、図も入れてあって「オブジェクトは参照経由でアクセスします」の ところはリンクにもしてありますから、よっぽど大丈夫なんじゃないかと思っています。 ご意見ありがとうございました。 (参照周りは、「参照渡し」とかでググると絶望するほどに誤解の多いところでは あるので、くどいぐらいに書いておいた方がよいのかもしれませんが)

読みました。 > そして、JavaScriptの関数がオブジェクトであるということは、 > 通常のオブジェクトと同じように、 > その参照値を変数に代入したり、関数の引数にしたり、 > 関数から戻り値として返したりできるということです この参照値という言葉は初出な気がするのですが、 私はJavaを少しかじったのでプリミティブ型と参照型があるんだなー となんとなくわかるのですが、 はじめてのプログラミングの方は「参照って何？」と思うかもしれません。 他のページで解説されている箇所があったらすみません。

>コンパイルエラーは警告ではなくエラーなので修正したほうがいいと思います。 ご指摘ありがとうございます。上の行をコピペしてそのままにしてしまいました。 修正しました。

「Webサーバを作りながら学ぶ 基礎からのWebアプリケーション開発入門」ダウンロード http://kmaebashi.com/webserver/download.html このページの > 2022/09/23追記：現状のソースだと、Tomcat10以降は警告が出ます。補足を参照してください。 コンパイルエラーは警告ではなくエラーなので修正したほうがいいと思います。 細かいことですがよろしくお願いいたします。

>>2311 変な書き込みをしてしまいすみません。

ご指摘ありがとうございます。 >* 10進数の20は16進数で14で文字はDC4 >* 10進数の32は16進数で20で文字はSP > 前のページ | 前のページ | ひとつ上のページに戻る | トップページに戻る 上記2点とも修正しました。 また何かありましたらよろしくお願いいたします。

（出先でChromebookで書いているのでリモートホストが変わっていますが） rike1019は同一人物です。 衝突判定と爆発――完全初心者のためのプログラミング入門 http://kmaebashi.com/programmer/beginner/collision.html このページの最下部のナビゲーションの「次のページ」のリンクが コピペでミスしたのか「前のページ」になっていて次のページに飛べません。 > 前のページ | 前のページ | ひとつ上のページに戻る | トップページに戻る 修正したほうがよろしいかと思います。いかがでしょうか？ よろしくお願いいたします。