C++相談室 part152

■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん
垢版 |
2020/07/12(日) 13:42:20.13ID:TX1mpKr6
https://mevius.5ch.net/test/read.cgi/tech/1589424805/
2020/09/24(木) 12:43:09.70ID:G65zjecI
>>547
boost::numeric::ublasとか使えばいい。
2020/09/24(木) 12:47:12.82ID:n05mXSO9
>>562
ああ確かに語順の変え方はprintfと変わらんな
auto time_v = time(nullptr);
cout << put_time(localtime(&time_v), "%m/%d/%y %H.%M'%S");
567デフォルトの名無しさん
垢版 |
2020/09/24(木) 13:45:56.89ID:sKL6gd3p
>>564
お前も本当にゴミだな
wikipediaのリンク貼っといてやるよ
ほら
https://ja.wikipedia.org/wiki/%E6%9B%B8%E5%BC%8F%E6%96%87%E5%AD%97%E5%88%97%E6%94%BB%E6%92%83
568デフォルトの名無しさん
垢版 |
2020/09/24(木) 13:47:01.22ID:sKL6gd3p
まじでバカはしね
2020/09/24(木) 14:13:22.68ID:n05mXSO9
その話のどこがバッファオーバーフローなんだ？
570デフォルトの名無しさん
垢版 |
2020/09/24(木) 14:23:05.33ID:sKL6gd3p
>コールスタック上のリターンアドレスを書き換えて不正なコードを実行させる
571デフォルトの名無しさん
垢版 |
2020/09/24(木) 14:24:13.29ID:sKL6gd3p
自分の過ちを認めろと言う割に自分は謝らず図々しく更に無駄な質問を重ねるとは
2020/09/24(木) 14:30:21.28ID:EUYXPM4X
>>565
boostは標準規格外なので却下
2020/09/24(木) 14:38:20.48ID:n05mXSO9
>>570
バッファオーバーフローさせるだけではコールスタック上のリターンアドレスは狙えないぜ
同じ記憶域期間を持つ他のオブジェクトを破壊する可能性があるというだけだ
コールスタック上のリターンアドレスを狙うなら配列でないオブジェクトのアドレスにオフセットかけるだけでもできるしな
逆に自動変数のアドレスを確実に得る技術が必要になる

printf/scanfといえばバッファオーバーフローという固定観念に囚われているから
そういう読みになっちまうんだよ
574デフォルトの名無しさん
垢版 |
2020/09/24(木) 14:46:00.53ID:sKL6gd3p
まともに日本語の文章も読めないようじゃプログラムは君には難しいよ
575デフォルトの名無しさん
垢版 |
2020/09/24(木) 14:49:15.10ID:sKL6gd3p
メモリ位置にあるデータを確認できると書いてあることすら読めてない
576デフォルトの名無しさん
垢版 |
2020/09/24(木) 14:54:12.15ID:0BhvwOmc
おまわりさんこのひとです
577デフォルトの名無しさん
垢版 |
2020/09/24(木) 14:55:32.81ID:sKL6gd3p
おとなしく、日本語もググるのも難しくてひとつずつ教えてもらわなきゃできません
ごめんなさいって言ってりゃいいのにｗ
2020/09/24(木) 14:59:43.90ID:n05mXSO9
>>575
俺、自動変数のアドレスを確実に得る技術って言ったけど
おまえさんは、これが何のことかわかってる？

printf/scanf関係ないんだがｗ
579デフォルトの名無しさん
垢版 |
2020/09/24(木) 15:11:43.38ID:sKL6gd3p
Wikipediaまで引用してあげたのにまだごねるのか
本当にわがままだな
580デフォルトの名無しさん
垢版 |
2020/09/24(木) 15:12:12.34ID:sKL6gd3p
ばかはしね
2020/09/24(木) 15:48:16.32ID:n05mXSO9
> printfはバッファオーバーフローの脆弱性を産みやすい

重箱の隅な記事では、最後の「やすい」という主張の裏付けにはならないってことだ
粗暴な罵倒語も裏付けになるわけがないな
582デフォルトの名無しさん
垢版 |
2020/09/24(木) 15:53:47.24ID:sKL6gd3p
そんなにprintf好きなら勝手に使えばいいんじゃない？
583デフォルトの名無しさん
垢版 |
2020/09/24(木) 16:06:33.08ID:0BhvwOmc
おまいら printf の戻り値は毎回チェックしろよ
2020/09/24(木) 16:26:18.33ID:VqYlbH9U
printfの書式にユーザ入力を使うことなんてあるか？
SQLインジェクションとはワケが違うぞ
2020/09/24(木) 17:02:36.61ID:EUYXPM4X
バッファ使ってるsprintfと
バッファ使ってないprintfの
違いもわからんのか
2020/09/24(木) 17:26:51.00ID:5Fx1JvjP
確かにprintfの書式文字列に関するメモリ破壊の脆弱性が示されてるが、これを｢バッファオーバーフロー｣と呼ぶのは違和感があるな
587デフォルトの名無しさん
垢版 |
2020/09/24(木) 17:33:32.86ID:sKL6gd3p
わかってないくせに危険な関数使うなよ
588デフォルトの名無しさん
垢版 |
2020/09/24(木) 17:34:56.21ID:sKL6gd3p
パフォーマンスとか以前の問題だろうが
589デフォルトの名無しさん
垢版 |
2020/09/24(木) 17:36:15.17ID:sKL6gd3p
>バッファ使ってるsprintfと
それ勝手に持ち出したのお前だからなｗ
2020/09/24(木) 18:19:48.23ID:7yQWIIk2
こっからどう乗り切る気？
2020/09/24(木) 18:21:49.52ID:9cj79wpF
結局のところ、>>542が恥ずかしい奴だったという結論でok?
592デフォルトの名無しさん
垢版 |
2020/09/24(木) 18:26:33.04ID:sKL6gd3p
>>591
お前みたいな頭悪いやつが多くて
何も有益な話にならないから解散
という結論
593デフォルトの名無しさん
垢版 |
2020/09/24(木) 18:37:51.09ID:sKL6gd3p
cout << ...
がダサいだのprintfが早いだの
程度が低いんだよ
2020/09/24(木) 18:48:48.99ID:TdIgAD6o
>>592
ん？
バッファーオーバーフローとメモリー破壊の区別もつかないアホがドヤって撃沈だろ？
ダサすぎるw
595デフォルトの名無しさん
垢版 |
2020/09/24(木) 18:53:55.27ID:sKL6gd3p
適当に脳内で読み替えとけや無能
こっちはprintfなんてそもそも使わんから詳しいことに興味はない
だからググれって最初に伝えたんだわ
596デフォルトの名無しさん
垢版 |
2020/09/24(木) 19:02:40.95ID:sKL6gd3p
>>594
じゃあメモリ破壊とバッファオーバーフロー
でリターンアドレスの書き換え方が
どう違うのか説明してみ
2020/09/24(木) 19:10:17.44ID:EUYXPM4X
ID真っ赤で必死ﾀﾞﾅw
598デフォルトの名無しさん
垢版 |
2020/09/24(木) 19:11:45.79ID:sKL6gd3p
逃げるのか？ｗ
599デフォルトの名無しさん
垢版 |
2020/09/24(木) 19:13:39.45ID:sKL6gd3p
ご自慢の知識を披露してみろよばかが
600デフォルトの名無しさん
垢版 |
2020/09/24(木) 19:44:29.22ID:sKL6gd3p
はい結局にげたー雑魚〜
2020/09/24(木) 19:56:55.65ID:55R+R5Lh
>>595
詳しいこと知らんのに
>>542で参戦してくるの？
振られたネタならともかく自分で振っといてwwww
602デフォルトの名無しさん
垢版 |
2020/09/24(木) 20:09:35.67ID:sKL6gd3p
printfに脆弱性ある
というのが重要な点なのにあくまでも上げ足取りをするのか
本当にごみしかいないな
2020/09/24(木) 20:10:35.38ID:EUYXPM4X
ID真っ赤で恥ずかしい奴w
604デフォルトの名無しさん
垢版 |
2020/09/24(木) 20:12:58.68ID:sKL6gd3p
なにが恥ずかしいの？IDすぐリセットされるし
2020/09/24(木) 20:25:09.79ID:7yQWIIk2
ほれぼれする雑魚っぷり
606デフォルトの名無しさん
垢版 |
2020/09/24(木) 20:27:17.41ID:sKL6gd3p
お前ほどではないよｗ
607デフォルトの名無しさん
垢版 |
2020/09/24(木) 20:32:02.13ID:sKL6gd3p
こういうのに反応してくるのは雑魚と相場が決まってるからなｗ
2020/09/24(木) 20:39:06.34ID:OqVmXa/U
>>596
それがprintfのバッファーオーバーフローと何か関係あるのか？
ごまかすならもう少しうまくやれよw
609デフォルトの名無しさん
垢版 |
2020/09/24(木) 20:42:06.80ID:sKL6gd3p
いや関係ないけど
どうせこいつもわかってないくせに人のこと煽ってるんだろうから
聞いてみたらやっぱ逃げた
2020/09/24(木) 20:56:41.05ID:n05mXSO9
printfはバッファオーバーフローの脆弱性を産みやすい
printfはバッファオーバーフローの脆弱性を産みやすい
printfはバッファオーバーフローの脆弱性を産みやすい

煽りモードに入るならボコボコにしてやんよ
611デフォルトの名無しさん
垢版 |
2020/09/24(木) 20:59:32.71ID:sKL6gd3p
>>610
どうぞご自由に
せいぜい頑張れよ無能なりに
2020/09/24(木) 21:00:05.83ID:NCTacveT
ここまで具体例を示した証拠も反論もなし。
2020/09/24(木) 22:12:13.40ID:jspEV3AF
>>542
今日日のIDEなら書式文字列とパラメータの型の不一致を指摘してくれる
Visual Studioなら2015からそうなっているので安心、
2020/09/24(木) 22:18:55.93ID:OqVmXa/U
>>611
で、どこのバッファーがオーバーフローするのかな？w
黙ってりゃいいのにバカは無駄に吠えるしか能がないから無理だろうな
2020/09/24(木) 22:50:51.72ID:jspEV3AF
sprintf()なら有り得る、
希ガス

個人的にはsprintf_s()しか使わないから無用の心配だが
2020/09/24(木) 22:53:03.50ID:55R+R5Lh
自分でバッファオーバーフロー言い出しといてなんやねん
2020/09/24(木) 22:54:48.84ID:jspEV3AF
std::ostringstreamは未来
そんなふうに考えていた時期が漏れにもありました、
2020/09/24(木) 23:04:17.15ID:lJ1l9qyF
https://code.woboq.org/userspace/glibc/stdio-common/vfprintf-internal.c.html#__vfprintf_internal
これかな。まぁ頑張って読んでくれ。
2020/09/24(木) 23:05:16.99ID:jspEV3AF
しかしなんでスタックって高位側から低位側に伸びる実装なんだろうな
逆にしたらそれだけで外部入力依存のバッファオーバーフローでexploitされる危険性を半減できるはず…
2020/09/24(木) 23:16:12.65ID:lJ1l9qyF
バイナリエディタ見てみろよ。アドレス高いほうが下だろ。
スタックはちゃんと下から積んでるんだよ。
2020/09/24(木) 23:45:08.26ID:jspEV3AF
ﾎﾝﾏにprintf()でもやれるんや、
https://www.ipa.go.jp/security/awareness/vendor/programmingv2/contents/c906.html

しかし%nはC++11で廃止されたとあるからモダンなC++ではprintf()は安心、
2020/09/24(木) 23:46:33.93ID:lJ1l9qyF
安全なライブラリ=チェックが多く遅いライブラリ

C使う意味なくね？
2020/09/24(木) 23:48:09.41ID:jspEV3AF
訂正orz、
誤： C++11
正： C11
2020/09/25(金) 00:19:45.11ID:nCkagqzh
>>619
それは昔々、CPUが今よりずっと低能力で、malloc()などをする余力もない時代、
メモリー領域を、普通の変数のワークエリアと、call命令での戻り値アドレスの
記憶のためと、レジスタの保存、復帰(push,pop)用のためのエリアを逆方向
から使うことは、画期的なアイデアだったから。
データ領域は、アドレスの小さい方から、大きいほうへ伸ばして使っていくが、
そうやってるさいにも、call,push,pop命令は使いたいから、そのようにする
以外には当時の非力なCPUには非効率すぎて選択肢が無かった。
今なら、リンクリストや高速なmalloc()などを駆使すれば、別の方法も取れるかも
知れない。
625デフォルトの名無しさん
垢版 |
2020/09/25(金) 00:26:39.90ID:nCkagqzh
>>624
[捕捉]
今は、マルチスレッドプログラミングをする際、各スレッドに、それぞれ
別のスタック領域を割り当てるが、その領域の容量は固定サイズ。
固定サイズでも何とかなるのは、メインメモリーが非常に大きくなったためで、
大部分は無駄になっていても、なんとかなってしまうから。
たとえば、関数呼び出しの回数と、ローカルスタック変数の容量を
掛け算したような値を見積もってみれば、とても無駄なスタック領域の
割り当てをしているだろうが、メモリーがふんだんに余る位になっているので
それでも特に問題がなくなってしまった。
ところが、かつてはメモリーが足りなくてどうしようもなかった。
しかも、当然当時はシングルスレッドだった。
なので、データ領域は上から、スタック領域は下から伸ばしていけば、
お互いが衝突するまで使える。これは、ギリギリ限界まで無駄なく
メモリーが使えることを意味する。
2020/09/25(金) 00:29:23.03ID:iQJ3d1Xe
なんかデタラメがいろいろ混じってるぞ。
2020/09/25(金) 00:30:59.73ID:7nm9kuAr
>>624
どこらへんが画期的で効率的なのかkwsk、
普通の変数のワークエリアと逆方向からスタックを伸ばしたところで
使えるメモリが増えるわけでなし…
（スレッドが2本以上あればスタック領域は結局スレッド毎に固定サイズで割り当てるしかない

百歩譲って一つながりのメモリを上と下の両方から使っていったらすばらしいと思えたとしても、
なんでスタックを0番地から上に伸ばしてsbrkが最大アドレスから下に伸びる設計にしなかったのかの
説明にならない
628デフォルトの名無しさん
垢版 |
2020/09/25(金) 00:34:29.83ID:nCkagqzh
>>625
[もっと捕捉]
今は、MMUを使っており、実際に使ってない仮想メモリー空間には、物理メモリー
を割り当てない。だから、使うまでは物理メモリーは無駄にはならない。
もう一つは、(仮想)アドレス空間自体が飛躍的に大きく取れるようになったことで、
搭載している物理メモリー以上に大きなアドレス空間が使えて、各スレッド
のスタック用に大きめにアドレス空間を確保(commit)しておけるように
なった。
32BIT時代ですら、4GBの仮想アドレス空間が使えたから、アドレス空間自体の
不足は余りおきなくなった。積んでいる物理メモリーよりも大きな空の領域を
各スレッドのスタックに割り当てても、特に問題が無い。
今や64BIT時代。同時に実行するスレッドの個数も増えつつあるが、各スタック
領域の仮想アドレス空間上のサイズを大きくとってもどうってことは無い時代になった。
しかし、かつてはそうではなく、スタックは下から上に伸ばして行き、データ領域
と衝突するまで使うのが良い方法だった。
2020/09/25(金) 00:47:42.60ID:iQJ3d1Xe
>>627
picの変態仕様見れば分かる。汎用機もそうだけどスタック制限あるアーキテクチャが普通だった時代。
しかも0番地から伸ばすとかCPUの仕組みすら知らんレベルだな。割り込みベクタがあったり、プログラムのROMがあったり、
0番地にフリーのRAMなどたいていない。つまり空いてるRAMの下限は開発が終了するまで確定しないこともしばしば。
じゃあいつSP設定値いつ決まるのって話。決まらないんだから一番うしろにして前に進めるのが頭使わずに済む。
ちなみに8086はスタックセグメントあるから。便利だろw
2020/09/25(金) 03:12:37.08ID:5q2rxyfR
>>622
ものによるんだろうが、たとえば配列へのアクセスがバッファーオーバーフローに
ならないかのチェック程度ならほどんど実行時のペナルティはないというデータはどこかで見たことがあるな。
正しいプログラムなら分岐予測がほぼ成功するから。

まあ結局のところは程度問題というか、許容可能な程度ならチェックしたっていいだろうし、
実際問題として全く異常系がないプログラムというものもそれはそれでありえないわけで。
2020/09/25(金) 05:15:46.56ID:Y7UfbpFk
>>629
よく8086のセグメントレジスタを糞呼ばわりするやついるけど
あれはあれで意外と合理性あったんだよな・・
2020/09/25(金) 06:14:47.70ID:cdg8K9Zm
>>622
ライブラリによってはデバッグ版とリリース版を持ってたりする
チェックを端折ることができるって言うのが売り
2020/09/25(金) 06:35:56.95ID:cdg8K9Zm
>>629
> なんかデタラメがいろいろ混じってるぞ。
お前が言うなよ…

> 0番地にフリーのRAMなどたいていない。
6800はダイレクトアドレッシングモード持ってるから0x0000〜0x00ffはRAM前提
6502も0x0000〜0x00ffがRAMでないと使い物にならないしスタック領域がハード的に決まってるにも関わらず後ろから使う設計だったりする
> じゃあいつSP設定値いつ決まるのって話
開発中にRAMの下限が変わったらSPの初期値の設定変えるだけだろ
2020/09/25(金) 06:40:05.92ID:cdg8K9Zm
>>631
想定している範囲内で使う分には効率いいし優れたアーキテクチャだと思う
想定している範囲がすぐに時代遅れになってしまったけど…
2020/09/25(金) 07:16:04.04ID:+l2B7ows
>>627
スタックポインタというものができた、8008から8080に進化した時の話なのよ

>一つながりのメモリを上と下の両方から使っていったらすばらしい
うん、それだけの話
若い番地にはプログラムを置くのよ、後ろからスタック、そんだけ
2020/09/25(金) 07:46:42.31ID:xGsH9qpm
mallocまで行かなくてもRAMが少ないからこそヒープからの固定長メモリブロックを使って省メモリしてたし、ヒープとスタックは別方向に取ったほうが最大限利用できた。
運が悪いとオーバーラップして誤動作するけど。
637デフォルトの名無しさん
垢版 |
2020/09/25(金) 07:51:02.31ID:UNwnFJoF
キャッシュ効率を上げるためにコーディング上でなにかできることある？
2020/09/25(金) 08:15:54.26ID:xSHyo3nF
あるよ
まずキャッシュ効率というのをどうやって計測しようとしているか書いてみ
639デフォルトの名無しさん
垢版 |
2020/09/25(金) 08:32:54.15ID:UNwnFJoF
プロファイラー
2020/09/25(金) 08:33:00.07ID:WvFHSXSD
>>629
ふふふ　皆その程度のことなどわかった上で
たわむれておるのだがn（ry

>>635
>若い番地にはプログラムを置くのよ、後ろからスタック、
プログラムがROM上なら別段RAMの先頭からスタック、で良いのでは…
プログラムをRAM上に転送してから実行するとしても、プログラムの末尾からスタック、で良いのでは…
ハンドアセンブルするときにプログラム末尾のアドレスが最後まで確定しないというのは却下
（ワークメモリをプログラムの末尾に配置するほうが数が
　プログラムの末尾アドレス確定後に決めなければならない定数が増えて大変なはず…
2020/09/25(金) 09:01:31.03ID:xSHyo3nF
>>639
じゃあ最適化ガイドのドキュメントあるでしょ？
がんばれ
642デフォルトの名無しさん
垢版 |
2020/09/25(金) 09:08:54.15ID:UNwnFJoF
>>641
わからないなら期待もたせるな
2020/09/25(金) 09:09:20.44ID:3+LaQyVV
メモリアクセスが狭い範囲に集中するように工夫する
可能な限りスレッド数を少なくタイムスライスを長くする
2020/09/25(金) 09:30:26.29ID:VqVKl+Zt
>>637
対象CPUのキャッシュアーキテクチャは何？
2020/09/25(金) 09:36:13.59ID:cdg8K9Zm
>>635
> スタックポインタというものができた、8008から8080に進化した時の話なのよ
知ったか乙
PDP-11にすでにスタックポインタはあるぞ
2020/09/25(金) 09:41:32.68ID:3+LaQyVV
80系に採用されたって話だろ
2020/09/25(金) 09:44:46.31ID:3+LaQyVV
てす
2020/09/25(金) 10:19:41.79ID:xSHyo3nF
>>642
ざっくりした内容で1行書き込めば
懇切丁寧に教えてもらえると思った？
2020/09/25(金) 10:35:33.35ID:cdg8K9Zm
>>646
PDP-11の時代からスタックは高位番地から使うようになってる
8080は（他のプロセッサも含めて）それに倣っただけ
2020/09/25(金) 12:11:23.00ID:3+LaQyVV
>>649
何で俺がそんな説明されるのかよくわからん
2020/09/25(金) 12:17:58.23ID:cdg8K9Zm
>>650
>>635の話じゃないと言うならいちいち横から絡んでこないでね、ウザいだけだし
652デフォルトの名無しさん
垢版 |
2020/09/25(金) 12:28:12.75ID:4ovx1Tzj
CSとSSが物理的に分けられるようになって意味が無くなった
2020/09/25(金) 12:32:13.75ID:iQJ3d1Xe
>>633
6502のアーキテクチャぐらい知ってるがな。だからたいていと言ってるだろ。
> SPの初期値の設定変えるだけだろ
当時の開発環境は紙の上とかが普通。ハンドアセンブル上等でみんなOPコード暗記してた。
ROM位置ズレました〜なんて言われたらちゃぶ台返しレベルの仕様変更。
8086のような相対値アドレスで比較的リロケータブルな環境は後になってから。
設定値を変えるだけだろとか簡単に言われても困る。

> PDP-11の時代からスタックは高位番地から使うようになってる
だったら当時はなぜそうなったか説明してくれないとな。
2020/09/25(金) 13:08:52.30ID:3+LaQyVV
>>651
646が絡んだことになってるのか
被害妄想の強い人だな
2020/09/25(金) 13:31:16.91ID:cdg8K9Zm
>>653
> 設定値を変えるだけだろとか簡単に言われても困る。
スタックへのアクセスってよほどトリッキーなことをしない限りSP相対だぞ
スタック領域変わったからと言ってSPの初期値以外に一体何を書き換えるんだよw
> だったら当時はなぜそうなったか説明してくれないとな。
それはPDP-11のアーキテクトに聞いてくれ
俺の指摘は8080ガーと言うのが的外れって言う話だから

>>654
いちいち絡んでくるなよ、気持ち悪いわ
2020/09/25(金) 13:43:22.03ID:3+LaQyVV
被害妄想というよりボキャ貧かｗ

なるほどな、今さらなことをドヤってるのも頭の更新が止まっている症状か
納得
657デフォルトの名無しさん
垢版 |
2020/09/25(金) 14:00:06.69ID:4ovx1Tzj
>頭の更新

ほんそれ
2020/09/25(金) 14:09:34.94ID:u87G89iw
>>652
でも、アセンブラならcall,push,pop,[ebp+xxx],[esp+xxx]はss:をしていなくても
勝手に stack segment相対になるから良いが、Cの引数にバッファのアドレスを
渡すような場合、ds:なのか、ss:なのかが分からないから、farアドレスにする
しかなくなってしまう。なので、ss=dsの状態にした方がCだと効率が良かった。
2020/09/25(金) 14:14:37.28ID:cdg8K9Zm
具体的に反論できないなら黙ってりゃいいのに…
2020/09/25(金) 14:20:55.55ID:MA61Hr7D
64ビットになったらセグメントなんてどうでもよくなったな
2020/09/25(金) 14:32:23.95ID:3+LaQyVV
対立してないのにどうやって反論するんだよ
それと何がどうだったという証言は論じゃないからな
2020/09/25(金) 14:42:12.89ID:cdg8K9Zm
>>661
お前はどうでもいいから無駄に絡んでくるな

>> 設定値を変えるだけだろとか簡単に言われても困る。
> スタックへのアクセスってよほどトリッキーなことをしない限りSP相対だぞ
> スタック領域変わったからと言ってSPの初期値以外に一体何を書き換えるんだよw
に対する答えが欲しいだけ
2020/09/25(金) 14:50:04.04ID:3+LaQyVV
>>662
おまえさんこそ俺が言ったことに反駁できてないな

喧嘩腰で来たのそっちだぜ
許して欲しいならちゃんとそう言えよ
まあ逃げても追わねえでやるけど
2020/09/25(金) 15:17:28.57ID:cdg8K9Zm
それこそ論点がないのにどう反駁しろと？
バカが横から絡んできて勝手にスッ転びました、どうしましょうか？
⇒ 放置しかないわなw
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況