問題タブ [memcpy]

どのような状況で memcpys が最新の INTEL/AMD ハードウェアの割り当てよりも優れていると期待できますか? 私は 32 ビット Intel プラットフォームで GCC 4.2.x を使用しています (ただし、64 ビットにも関心があります)。

と呼ばれるいくつかのポインタがあるとしましょう：

どちらも他の場所を指すメモリアドレスを保持するだけであり、型は特定のポインタが指すメモリの場所の大きさを宣言することを知っています。たとえば、char はシステム上の 1 バイトのサイズであり、int は 4 バイトである可能性があります。

しかし、私がこれを行うとどうなりますか：

ありがとう..ここで説明をいただければ幸いです..ポインタ型は単に ++ 操作のためですか?

編集: avp は私の質問に適切に答えましたが、フォローアップの質問があります。

2バイトコピーしますか？または4バイト？アクセス違反になりますか？

編集: Ryan Fox によると、答えは (void*) に型キャストされているため、2 バイトです。ありがとう！閉まっている！

編集：将来の検索者がこれを見つけることができるように..私が発見した別の情報..

pInt+5bytelocations が指すメモリ ブロックの 2 バイトを pChar+5bytelocations にコピーしません。2 バイトが pInt(4*5)bytelocations から pChar+5bytelocations にコピーされます。アクセス違反が発生したのも不思議ではありません。読んではいけないところを読もうとしていた.. :)

int、char、および char の配列が混在する構造体のメンバーをバイト配列にコピーして、シリアル回線に送信しようとしています。これまでのところ、

このコードを入手したので、それがどのように機能するかを完全には理解していません。memcpy が構造体の各要素を取得し、それを「i」変数によってインデックス付けされたシリアル ストリームにすることがわかりますが、USARTWrite 関数がこれをどのように文字列にパケット化するか、または配列を次のようにロードする方法はわかりません私の構造体の初期化。

申し訳ありませんが、この投稿は少し長くなりますが、私はこのプログラミングのひばりを始めたばかりで、この概念を理解しようとしています.

ありがとうデイブ

編集：

うわー、多くの良い答えがすぐに出ます - みんなありがとう。

slaz: それは私には論理的に思えます.私はまだポインタについて頭を悩ませていないので,そのアプローチについてはあまり考えていませんでしたが.見て。

• このコード行はデータを UART に送信します。メッセージの内容を含む配列を何に置き換えますか? ここでは、構造の開始位置と大きさを示す変数があるが、送信する配列がないという論理的なステップが欠落しているようです

  /li>

ハーパー・シェルビー: その説明をありがとう。

rgds

デイブ

strcpy()Cの機能が悪い、悪いと思っている人もいるようです。strncpy()通常はバッファ オーバーフローを回避するために使用する方がよいことは認めますが、次の (このstrdup()関数を使用することができなかった人のための関数の実装) は、安全に使用し、オーバーフローすることはstrcpy()ありません。

*s2を保存するのに十分なスペースがあることが保証されており*s1、を使用するとstrcpy()、結果を別の関数に保存して、strlen()後で不要な (この場合) の長さパラメーターとして使用する必要がなくなりますstrncpy()。しかし、長さパラメータを必要とするや を使ってこの関数を書く人strncpy()もいます。memcpy()人々がこれについてどう思うか知りたいです。特定の状況で安全だと思う場合strcpy()は、そう言ってください。このような状況で使用しない正当な理由がある場合は、それを教えてください。このような状況で使用するstrcpy()方がよい理由を知りたいです。大丈夫だと思うが、ここにない場合は、説明してください。strncpy()memcpy()strcpy()

memcpy()基本的に、他の人が使用するときに使用する人strcpy()もいれば、プレーンを使用する人もいる理由を知りたいだけですstrncpy()。3つよりも1つを優先するロジックはありますか(最初の2つのバッファチェックを無視します)?

DDR3 デュアル チャネル メモリを搭載した Core 2 プロセッサのメモリ帯域幅の理論上の最大値は印象的です。アーキテクチャに関するウィキペディアの記事によると、 1 秒あたり 10+ または 20+ ギガバイトです。ただし、標準の memcpy() 呼び出しではこれを達成できません。(3 GB/s は、このようなシステムで見た中で最高です。) おそらく、これは、プロセッサの特性に基づいてすべてのプロセッサ ラインに対して memcpy() を調整するという OS ベンダーの要件によるものです。幅広いブランドやラインで妥当なはずです。

私の質問: C プログラムで利用できる、Core 2 または Core i7 プロセッサ用に高度に調整された自由に利用できるバージョンはありますか? これを必要としているのは私だけではないと確信しており、誰もが自分の memcpy() をマイクロ最適化するのは大変な労力の無駄です。

間違った結果を出力しているこのコードがあります。

私が得る出力は

バイト0xc0000000float-2.000001e + 00

私は得ることを期待しています

バイト0xdeadbeeffloat-6.2598534e + 18

エンディアンが異なる可能性があると指摘されたように、＃1を編集すると、次のようになります。

バイト0xefbeaddefloat-1.1802469e + 29

私が理解していないのは、floatからunsigned intへのキャストで0xc0000000になります（同じprintfステートメントのfloatは-2.0000であり、コンパイラの最適化に起因します）

これは以前は別のコンピューターで機能していました。アーキテクチャの変更である可能性があります。

ソースメモリをCPUキャッシュにロードしないmemcpy関数を書き込もうとしています。目的は、キャッシュ汚染を回避することです。以下の memcpy 関数は機能しますが、標準の memcpy のようにキャッシュを汚染します。Visual C++ 2008 Express で P8700 プロセッサを使用しています。Intel vtune で CPU キャッシュの使用状況が表示されます。

同じ結果が得られる別のバージョンがあります-動作しますが、キャッシュを汚染します。

更新：これはテストプログラムです

私は最近、Microsoftが安全なプログラミングショップでの機能を禁止していると主張する記事に出くわしました。memcpy()関数に固有の脆弱性は理解していますが、その使用を完全に禁止する必要がありますか？

私が書いたプログラムはmemcpy()完全に回避するべきですか、それとも単に安全に使用されることを保証するべきですか？同様であるがより安全な機能を提供する代替案は何ですか？

複製：

安全なプログラミングで Memcpy()?

「 memcpy() を SDL Rogues Gallery に歓迎するために参加してください」によるとmemcpy、安全ではないとして禁止されています。gets()、strcpyおよび宛先サイズが不明な同様の APIは理にかなっています。memmove()次は？

ご存知かもしれませんが、Microsoftはmemcpy()セキュリティ開発ライフサイクルを禁止し、に置き換えましたmemcpy_s()。

したがって、コードが以前は次のようになっていた場合：

あれは。。。になる：

または、切り捨てを使用して、

vs

質問：余分な長さのパラメーターはどのようにしてコードをより安全にするのですか？を使用するmemcpy()には、4つのパラメーターすべてがわかっていて、3番目の引数として適切な長さを渡す必要があります。宛先バッファサイズを誤って計算し、間違った値を渡すという同じ間違いをするのを妨げているのはdst_size何ですか？なぜそれが違うのかmemcpy()、なぜ非推奨になっているのかわかりません。見えない一般的なユースケースはありますか？ここで何が欠けていますか？