C++相談室 part152
■ このスレッドは過去ログ倉庫に格納されています
>>535
たとえばだけど、二次元配列がいるならクラス化するとかね
人によるだろうけどvector<vector<int>>は俺あんまりやりたくない 用意されているものを使っただけだろ
意地でもとかバイアスが入るのはコンプレックスの顕れだからこそ
ギャンギャン強弁してくるわけだ >>542
printfでバッファオーバーフロー?
お前器用なやつだな decayに_t付けるの忘れてた
>>548
それ誰に向けて言ってるの? なんか口調でわかるわ、いつものアホか・・・
「>」これが付いてるのは引用箇所だからな、覚えとくといいよw printf, scanf系はtypedef型の正体を知っておかねばならないとかクラス型を基本型と同等に扱えないとかモロモロあるのに
いつまでもマンセーしててもしゃーないで >>549
いや普通にありえるからググってわかる程度のこと聞くなよ >>555
typedefの正体を意識してprintf/scanfを使うのは
privateでデータメンバを隠す話と真っ向逆だね 最終出力がわかりにくいとかロケール対応しにくいとかあるわけだけど
引数順にしか出力できない時点でprintfもロケール対応のやりにくさは変わらん ググりかたから教えなきゃならんの?
相手にしてられんわ >>558
そんなあなたにput_money, put_time >>561
ロケールと書いたのが悪かったな
多言語化だな
語順を変えるとかやりにくい
Pythonのようにフォーマット文に引数の順番をかければ
言語による語順の違いもフォーマット文の差し替えだけで済む >>556
ググれー
で逃げる気マンマンでワロタ
おとなしくsprintfでした、ごめんなさい
って言ってりゃいいのにw >>547
boost::numeric::ublasとか使えばいい。 >>562
ああ確かに語順の変え方はprintfと変わらんな
auto time_v = time(nullptr);
cout << put_time(localtime(&time_v), "%m/%d/%y %H.%M'%S"); >コールスタック上のリターンアドレスを書き換えて不正なコードを実行させる 自分の過ちを認めろと言う割に自分は謝らず図々しく更に無駄な質問を重ねるとは >>570
バッファオーバーフローさせるだけではコールスタック上のリターンアドレスは狙えないぜ
同じ記憶域期間を持つ他のオブジェクトを破壊する可能性があるというだけだ
コールスタック上のリターンアドレスを狙うなら配列でないオブジェクトのアドレスにオフセットかけるだけでもできるしな
逆に自動変数のアドレスを確実に得る技術が必要になる
printf/scanfといえばバッファオーバーフローという固定観念に囚われているから
そういう読みになっちまうんだよ まともに日本語の文章も読めないようじゃプログラムは君には難しいよ メモリ位置にあるデータを確認できると書いてあることすら読めてない おとなしく、日本語もググるのも難しくてひとつずつ教えてもらわなきゃできません
ごめんなさいって言ってりゃいいのにw >>575
俺、自動変数のアドレスを確実に得る技術って言ったけど
おまえさんは、これが何のことかわかってる?
printf/scanf関係ないんだがw Wikipediaまで引用してあげたのにまだごねるのか
本当にわがままだな > printfはバッファオーバーフローの脆弱性を産みやすい
重箱の隅な記事では、最後の「やすい」という主張の裏付けにはならないってことだ
粗暴な罵倒語も裏付けになるわけがないな そんなにprintf好きなら勝手に使えばいいんじゃない? おまいら printf の戻り値は毎回チェックしろよ printfの書式にユーザ入力を使うことなんてあるか?
SQLインジェクションとはワケが違うぞ バッファ使ってるsprintfと
バッファ使ってないprintfの
違いもわからんのか 確かにprintfの書式文字列に関するメモリ破壊の脆弱性が示されてるが、これを「バッファオーバーフロー」と呼ぶのは違和感があるな >バッファ使ってるsprintfと
それ勝手に持ち出したのお前だからなw 結局のところ、>>542が恥ずかしい奴だったという結論でok? >>591
お前みたいな頭悪いやつが多くて
何も有益な話にならないから解散
という結論 cout << ...
がダサいだのprintfが早いだの
程度が低いんだよ >>592
ん?
バッファーオーバーフローとメモリー破壊の区別もつかないアホがドヤって撃沈だろ?
ダサすぎるw 適当に脳内で読み替えとけや無能
こっちはprintfなんてそもそも使わんから詳しいことに興味はない
だからググれって最初に伝えたんだわ >>594
じゃあメモリ破壊とバッファオーバーフロー
でリターンアドレスの書き換え方が
どう違うのか説明してみ >>595
詳しいこと知らんのに
>>542で参戦してくるの?
振られたネタならともかく自分で振っといてwwww printfに脆弱性ある
というのが重要な点なのにあくまでも上げ足取りをするのか
本当にごみしかいないな こういうのに反応してくるのは雑魚と相場が決まってるからなw >>596
それがprintfのバッファーオーバーフローと何か関係あるのか?
ごまかすならもう少しうまくやれよw いや関係ないけど
どうせこいつもわかってないくせに人のこと煽ってるんだろうから
聞いてみたらやっぱ逃げた printfはバッファオーバーフローの脆弱性を産みやすい
printfはバッファオーバーフローの脆弱性を産みやすい
printfはバッファオーバーフローの脆弱性を産みやすい
煽りモードに入るならボコボコにしてやんよ >>610
どうぞご自由に
せいぜい頑張れよ無能なりに >>542
今日日のIDEなら書式文字列とパラメータの型の不一致を指摘してくれる
Visual Studioなら2015からそうなっているので安心、 >>611
で、どこのバッファーがオーバーフローするのかな?w
黙ってりゃいいのにバカは無駄に吠えるしか能がないから無理だろうな sprintf()なら有り得る、
希ガス
個人的にはsprintf_s()しか使わないから無用の心配だが 自分でバッファオーバーフロー言い出しといてなんやねん std::ostringstreamは未来
そんなふうに考えていた時期が漏れにもありました、 しかしなんでスタックって高位側から低位側に伸びる実装なんだろうな
逆にしたらそれだけで外部入力依存のバッファオーバーフローでexploitされる危険性を半減できるはず… バイナリエディタ見てみろよ。アドレス高いほうが下だろ。
スタックはちゃんと下から積んでるんだよ。 安全なライブラリ=チェックが多く遅いライブラリ
C使う意味なくね? >>619
それは昔々、CPUが今よりずっと低能力で、malloc()などをする余力もない時代、
メモリー領域を、普通の変数のワークエリアと、call命令での戻り値アドレスの
記憶のためと、レジスタの保存、復帰(push,pop)用のためのエリアを逆方向
から使うことは、画期的なアイデアだったから。
データ領域は、アドレスの小さい方から、大きいほうへ伸ばして使っていくが、
そうやってるさいにも、call,push,pop命令は使いたいから、そのようにする
以外には当時の非力なCPUには非効率すぎて選択肢が無かった。
今なら、リンクリストや高速なmalloc()などを駆使すれば、別の方法も取れるかも
知れない。 >>624
[捕捉]
今は、マルチスレッドプログラミングをする際、各スレッドに、それぞれ
別のスタック領域を割り当てるが、その領域の容量は固定サイズ。
固定サイズでも何とかなるのは、メインメモリーが非常に大きくなったためで、
大部分は無駄になっていても、なんとかなってしまうから。
たとえば、関数呼び出しの回数と、ローカルスタック変数の容量を
掛け算したような値を見積もってみれば、とても無駄なスタック領域の
割り当てをしているだろうが、メモリーがふんだんに余る位になっているので
それでも特に問題がなくなってしまった。
ところが、かつてはメモリーが足りなくてどうしようもなかった。
しかも、当然当時はシングルスレッドだった。
なので、データ領域は上から、スタック領域は下から伸ばしていけば、
お互いが衝突するまで使える。これは、ギリギリ限界まで無駄なく
メモリーが使えることを意味する。 >>624
どこらへんが画期的で効率的なのかkwsk、
普通の変数のワークエリアと逆方向からスタックを伸ばしたところで
使えるメモリが増えるわけでなし…
(スレッドが2本以上あればスタック領域は結局スレッド毎に固定サイズで割り当てるしかない
百歩譲って一つながりのメモリを上と下の両方から使っていったらすばらしいと思えたとしても、
なんでスタックを0番地から上に伸ばしてsbrkが最大アドレスから下に伸びる設計にしなかったのかの
説明にならない >>625
[もっと捕捉]
今は、MMUを使っており、実際に使ってない仮想メモリー空間には、物理メモリー
を割り当てない。だから、使うまでは物理メモリーは無駄にはならない。
もう一つは、(仮想)アドレス空間自体が飛躍的に大きく取れるようになったことで、
搭載している物理メモリー以上に大きなアドレス空間が使えて、各スレッド
のスタック用に大きめにアドレス空間を確保(commit)しておけるように
なった。
32BIT時代ですら、4GBの仮想アドレス空間が使えたから、アドレス空間自体の
不足は余りおきなくなった。積んでいる物理メモリーよりも大きな空の領域を
各スレッドのスタックに割り当てても、特に問題が無い。
今や64BIT時代。同時に実行するスレッドの個数も増えつつあるが、各スタック
領域の仮想アドレス空間上のサイズを大きくとってもどうってことは無い時代になった。
しかし、かつてはそうではなく、スタックは下から上に伸ばして行き、データ領域
と衝突するまで使うのが良い方法だった。 >>627
picの変態仕様見れば分かる。汎用機もそうだけどスタック制限あるアーキテクチャが普通だった時代。
しかも0番地から伸ばすとかCPUの仕組みすら知らんレベルだな。割り込みベクタがあったり、プログラムのROMがあったり、
0番地にフリーのRAMなどたいていない。つまり空いてるRAMの下限は開発が終了するまで確定しないこともしばしば。
じゃあいつSP設定値いつ決まるのって話。決まらないんだから一番うしろにして前に進めるのが頭使わずに済む。
ちなみに8086はスタックセグメントあるから。便利だろw >>622
ものによるんだろうが、たとえば配列へのアクセスがバッファーオーバーフローに
ならないかのチェック程度ならほどんど実行時のペナルティはないというデータはどこかで見たことがあるな。
正しいプログラムなら分岐予測がほぼ成功するから。
まあ結局のところは程度問題というか、許容可能な程度ならチェックしたっていいだろうし、
実際問題として全く異常系がないプログラムというものもそれはそれでありえないわけで。 >>629
よく8086のセグメントレジスタを糞呼ばわりするやついるけど
あれはあれで意外と合理性あったんだよな・・ >>622
ライブラリによってはデバッグ版とリリース版を持ってたりする
チェックを端折ることができるって言うのが売り >>629
> なんかデタラメがいろいろ混じってるぞ。
お前が言うなよ…
> 0番地にフリーのRAMなどたいていない。
6800はダイレクトアドレッシングモード持ってるから0x0000〜0x00ffはRAM前提
6502も0x0000〜0x00ffがRAMでないと使い物にならないしスタック領域がハード的に決まってるにも関わらず後ろから使う設計だったりする
> じゃあいつSP設定値いつ決まるのって話
開発中にRAMの下限が変わったらSPの初期値の設定変えるだけだろ >>631
想定している範囲内で使う分には効率いいし優れたアーキテクチャだと思う
想定している範囲がすぐに時代遅れになってしまったけど… >>627
スタックポインタというものができた、8008から8080に進化した時の話なのよ
>一つながりのメモリを上と下の両方から使っていったらすばらしい
うん、それだけの話
若い番地にはプログラムを置くのよ、後ろからスタック、そんだけ mallocまで行かなくてもRAMが少ないからこそヒープからの固定長メモリブロックを使って省メモリしてたし、ヒープとスタックは別方向に取ったほうが最大限利用できた。
運が悪いとオーバーラップして誤動作するけど。 キャッシュ効率を上げるためにコーディング上でなにかできることある? あるよ
まずキャッシュ効率というのをどうやって計測しようとしているか書いてみ >>629
ふふふ 皆その程度のことなどわかった上で
たわむれておるのだがn(ry
>>635
>若い番地にはプログラムを置くのよ、後ろからスタック、
プログラムがROM上なら別段RAMの先頭からスタック、で良いのでは…
プログラムをRAM上に転送してから実行するとしても、プログラムの末尾からスタック、で良いのでは…
ハンドアセンブルするときにプログラム末尾のアドレスが最後まで確定しないというのは却下
(ワークメモリをプログラムの末尾に配置するほうが数が
プログラムの末尾アドレス確定後に決めなければならない定数が増えて大変なはず… >>639
じゃあ最適化ガイドのドキュメントあるでしょ?
がんばれ メモリアクセスが狭い範囲に集中するように工夫する
可能な限りスレッド数を少なくタイムスライスを長くする >>637
対象CPUのキャッシュアーキテクチャは何? >>635
> スタックポインタというものができた、8008から8080に進化した時の話なのよ
知ったか乙
PDP-11にすでにスタックポインタはあるぞ ■ このスレッドは過去ログ倉庫に格納されています