C++相談室 part152
■ このスレッドは過去ログ倉庫に格納されています
>>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にすでにスタックポインタはあるぞ >>642
ざっくりした内容で1行書き込めば
懇切丁寧に教えてもらえると思った? >>646
PDP-11の時代からスタックは高位番地から使うようになってる
8080は(他のプロセッサも含めて)それに倣っただけ >>649
何で俺がそんな説明されるのかよくわからん >>650
>>635の話じゃないと言うならいちいち横から絡んでこないでね、ウザいだけだし CSとSSが物理的に分けられるようになって意味が無くなった >>633
6502のアーキテクチャぐらい知ってるがな。だからたいていと言ってるだろ。
> SPの初期値の設定変えるだけだろ
当時の開発環境は紙の上とかが普通。ハンドアセンブル上等でみんなOPコード暗記してた。
ROM位置ズレました〜なんて言われたらちゃぶ台返しレベルの仕様変更。
8086のような相対値アドレスで比較的リロケータブルな環境は後になってから。
設定値を変えるだけだろとか簡単に言われても困る。
> PDP-11の時代からスタックは高位番地から使うようになってる
だったら当時はなぜそうなったか説明してくれないとな。 >>651
646が絡んだことになってるのか
被害妄想の強い人だな >>653
> 設定値を変えるだけだろとか簡単に言われても困る。
スタックへのアクセスってよほどトリッキーなことをしない限りSP相対だぞ
スタック領域変わったからと言ってSPの初期値以外に一体何を書き換えるんだよw
> だったら当時はなぜそうなったか説明してくれないとな。
それはPDP-11のアーキテクトに聞いてくれ
俺の指摘は8080ガーと言うのが的外れって言う話だから
>>654
いちいち絡んでくるなよ、気持ち悪いわ 被害妄想というよりボキャ貧かw
なるほどな、今さらなことをドヤってるのも頭の更新が止まっている症状か
納得 >>652
でも、アセンブラならcall,push,pop,[ebp+xxx],[esp+xxx]はss:をしていなくても
勝手に stack segment相対になるから良いが、Cの引数にバッファのアドレスを
渡すような場合、ds:なのか、ss:なのかが分からないから、farアドレスにする
しかなくなってしまう。なので、ss=dsの状態にした方がCだと効率が良かった。 64ビットになったらセグメントなんてどうでもよくなったな 対立してないのにどうやって反論するんだよ
それと何がどうだったという証言は論じゃないからな >>661
お前はどうでもいいから無駄に絡んでくるな
>> 設定値を変えるだけだろとか簡単に言われても困る。
> スタックへのアクセスってよほどトリッキーなことをしない限りSP相対だぞ
> スタック領域変わったからと言ってSPの初期値以外に一体何を書き換えるんだよw
に対する答えが欲しいだけ >>662
おまえさんこそ俺が言ったことに反駁できてないな
喧嘩腰で来たのそっちだぜ
許して欲しいならちゃんとそう言えよ
まあ逃げても追わねえでやるけど それこそ論点がないのにどう反駁しろと?
バカが横から絡んできて勝手にスッ転びました、どうしましょうか?
⇒ 放置しかないわなw >>655
>SP相対
なんだよこれ。非力なチップでスタックフレームの実装でも始める気か?
8086のようなスタックフレーム考慮した楽ちんアドレッシングとかおまえの指摘は時代錯誤が多い。
当時のデバイスもROMやテープが当たり前だし設定値変えるだけとかほんと簡単に言ってくれる。
だいたい先頭にスタック置いて、今度はどうやってワークエリアの位置を確定する気だよ。
結局確定しないから後ろからってなるだけだ。 >>665
また意味不明なことを言い出した
まあ低能にありがちな行動だけどw
>>666
push/popってSP相対だろ
> 当時のデバイスもROMやテープが当たり前だし設定値変えるだけとかほんと簡単に言ってくれる。
どうせ変更するのにSPの初期値を変えるのが面倒とか意味わからん
ちなみに俺は8bit時代からの組込み屋でテープもEP-ROMも使ってたから当時の話とかでごまかそうとしても無駄だよ
> だいたい先頭にスタック置いて、今度はどうやってワークエリアの位置を確定する気だよ。
後ろから取ればいいだけだろ
ただなんとなく気持ち悪いから前からワークエリア、後ろからスタックってなっただけだと思うよ 否定しないなあw
スタックへのアクセスはpush/popだけとか
自動変数にポインタ経由でアクセスするのがトリッキーとか
何だろこの人w > EP-ROMも使って【た】
過去形だね
C++でファームウエア書いてないってことか >>667
なぜSPは後ろからという議論なんだから結論を先に言えよ。先に言ってりゃおまえとは議論しないんだよ。
> ただなんとなく気持ち悪いから >>668
> 自動変数にポインタ経由でアクセスするのがトリッキーとか
それSP相対になるだろ
とりあえず
> スタック領域変わったからと言ってSPの初期値以外に一体何を書き換えるんだよw
の答えを考えてからレスしろよ…
>>669
えっ、まだEP-ROM使ってるの?
紫外線イレーザーが現役とかすげーなw >>670
結論じゃねーよ、俺の勝手な想像だ
日本語も理解できてないアホはこれだから… >>671
ならねえよ
void func(int* p)
{
*p = 1; //代入先が自動変数か否かはわからんだろ
}
おまえさん、左辺値pから右辺値をpopで取り出すとか思ってそうだな EEPROM知らねえらしいな
マジ頭の更新止まってやんのw >>673
呼ばれた側は自動変数かどうかなんて意識する必要ないだろ…
それ自動変数へのポインタを引数にして呼ぶ側のコード考えたらわかると思うけど
>>674
ん?
EEPROM知らないとかどこから出てきたんだ?
EP-ROMでバカにされて発狂の図?w >>675
自動変数かどうかわからんものへのアクセスをSP相対にできるのかって話だよ
重箱の隅ではないごく一般的なケースだぞ
ここC++スレだぜ? this->すげー多用するんだが
UV-EPROMのまま更新が止まった頭じゃ思い至らんかったか >>676
> 自動変数かどうかわからんものへのアクセスをSP相対にできるのかって話だよ
だから自動変数へのポインタを求めるのは呼び出し側でSP相対で計算してるだろ
呼ばれた側は単なるアドレスになってるから関係ない
C/C++の基礎だぞ、まじでわかってないのか?
EP-ROMとか言う前にちょっとは考えろよw >>667
> 8bit時代からの組込み屋でテープもEP-ROMも使ってた
このスレ凄い人おるんやな
素直に感心したわ >>678
ごめんなホレリスカード使ってたわ
それと2500feetのオープンリールとかね >>678
別に凄くはないよ
そういう時代に仕事してたってだけの話
もうすぐ定年だけど正直仕事としては当時の方が面白かったな
まあ時代が上り坂だったせいもあるけど >>677
this->がどう翻訳されているのか覗いてみたことがないから
スタックへのアクセスはほとんどがSP相対だなんて大きく出たんだろ
おまえマジC++でROM焼きしてねえだろ >>681
> this->がどう翻訳されているのか覗いてみたことがないから
C++はスタティックとかヒープとかにインスタンス置けるから一概には言えんけど自動変数としてインスタンスを生成したらthisポインタはSP相対になるだろ
ならない例があるとでも言うのか?
> おまえマジC++でROM焼きしてねえだろ
まあC++のROM焼は確かにあまりないな
ROM焼きするのは8bitはほぼアセンブラだし、16bitでもC言語だったし
ただC言語でもスタック上に生成した構造体へのポインタはC++のthisポインタと同じだしな
アセンブルリスト見たらすぐわかる話 >>679
褒めて欲しいん?
>>680
謙遜しなさんな(`・ω・´)ゞ 俺も含めてオッサンしかいないスレw
オッサン同士仲良くしようぜ。 >>682
C++でROM焼きしてねえんだな?
このスレではゴミだぜ、クズだぜ
そこ弁えろな、ゴミクズ
thisがSPとか寝言ぬかしてんじゃねえ スタックに必要なサイズを求めるのはとても面倒だった。
だから、予め決まった領域を割り当てるのは不可能に近かったので、
データ領域とは逆さまに、データ領域が最後まで使わない部分をスタック
領域とし、暴走しない限りはスタックが足りていると判断する(笑)と言う
当時としては合理的な方法が採用された。
この方式だと、スタックサイズが見積もれなくても、問題が無い。
本等はスタックが足りているかどうかは、暴走したかどうかではなく、
機械語モニタなどで、スタック付近をダンプしてみて、00h以外の値が
ある部分がスタックが使用されている領域とみなすことが出来た。 >>682
もちろん、その関数の中ではsp相対になる。
しかし、C言語では、ローカル変数のアドレスを他の関数に渡す。
一方、グローバル変数のアドレスも同じ方式で他の関数に渡す。
で、どちらからきたアドレス化を区別する方法が基本的には無い。
区別するためには、far pointer といって、普通のアドレス以外にセグメントアドレス
を合わせた長いポインタを渡す必要があった。
しかし、それは何かと効率が悪かった。
そこで、Windowsは32BIT化したときに、far pointerを使わずに済ますため、
(大体で言えば)セグメントを全て共通のベースアドレスとサイズを持つようにし、
「Full Flat」方式を採用した。
これで、ポインタ渡したり記録したりするための領域が短くて済み、
効率が上がった。 >>685
で、SP相対にならない例はあるんか?
>>679見る限り汎用機のオペレーターさんみたいだからあまり無理すんなw >>689
だからthisな
どっから値もらってきたかは関係ねえの
わかったか? ゴミクズ >>688
sp 相対アドレッシングって 6809 以外にはなにがあるのですか? >>691
x86系は、[esp+xxx]が使える。
[ebp+xxx]も、ebpを関数の先頭でespを記録するから、同じこと。 >>688
申し訳ないけどfarポインタの話は頓珍漢だしややこしくなるだけだよ
セグメントレジスタはSSとDSだけじゃなくてCSやESもあるし、そもそもローカル変数とグローバル変数を区別するためのもんじゃないし
>>690
>>663w ■ このスレッドは過去ログ倉庫に格納されています