問題タブ [calloc]

私はリングバッファを実装しています.1つの方法でCHUNKSIZEは、ループ内のファイルからバイトを読み取り、ポインタをリングバッファに挿入しています。

私はwhileループでこれをやっています。コードは問題mallocなく動作callocしますが、ループの最後で segfault が発生します。これは本当に謎です。

コードは次のとおりです。

これは、このWebサイトでの私の最初の質問です。

私は大学の課題のためにCプログラムを作成しています。それはゲームです。callocを使用して、構造体の配列にメモリを動的に割り当てました。次に、ファイル（fwriteによって既に同じ構造が書き込まれている）から読み取り、callocから作成したこれらの構造に情報を格納しています。次に、情報を処理してファイルに書き戻します。私が直面している問題は、「wb」を使用して同じファイルを上書きし、処理された構造をfwriteで書き戻すと、配列の最初の構造のみが書き込まれ、他の構造は何らかの理由で書き込まれず、メモリから失われることです。fwriteを使用する前は、すべての情報がメモリ内にそのまま残っていると確信しています。だから、私は処理で何も悪いことをしていません。しかし、fwriteは最初の構造以上のものを書きません。どんな助けでも大歓迎です。コードの一部は次のとおりです。

C 関数の malloc と calloc をいじっていて、いくつか質問があります。

これら2つの関数を使用して物理メモリのみを割り当てることができるかどうかを確認したいのですが、私のMacには4GBまたはRAMがあり、mallocを使用すると4GBを超える方法を割り当てることができます。つまり、mallocは物理メモリと仮想メモリの両方を割り当てます。

いくつか質問があります。

1. 物理メモリのみを割り当てることができるように、使用できる関数はありますか (仮想メモリの割り当てなし)

2. malloc と calloc を呼び出すとき、およびポインターが返されるときに、ポインターを使用して、割り当てられている物理メモリの量と割り当てられている仮想メモリの量を判断する方法はありますか?

簡単な例は本当に高く評価されます:)

ご協力いただきありがとうございます ：）

次のCパズルの質問について考え直します。Cプログラマーがこれ以上の経験をどのように考えているのか興味があります...サンプルコードを見てください。

上記のstrdup（）の提案された実装には、各呼び出しで一貫して表示されない可能性のあるランタイムエラーが含まれています。次のうち、このエラーを正確に説明しているのはどれですか？

これに対する考えられる答えは次のとおりです。

1 calloc（）の引数により、sの内容を格納するために十分なメモリが割り当てられません。

2メモリが不足している場合、calloc（）は失敗し、NULLを返す可能性があります。コードはこの状態を予期していません。

3 memcpy（）を使用してASCII文字列をコピーすると、データが破損する可能性があります。

4 bufはNULで終了することはないため、文字列に影響を与えるCライブラリ関数では使用できません。

5この関数は、動的メモリへのポインタを返します。この方法は避ける必要があり、常にメモリリークを構成します。

私が思ったのは、正解は2ですが、答え2がすぐに正しいというよりも、他の答えが間違っているように見えるからです。

• callocは文字列を適切に終了するのに十分なメモリ（len + 1）を予約しているため、回答1は正しくないようです。

• 回答3に書かれていることについては何も知りません。

• answer4：memcpyはsの内容をbufにコピーし、最後のバイトを0に残します（lenバイトをコピーします。callocへの以前の呼び出しは最後のバイトを0で埋めたことに注意してください）。したがって、この答えは正しくありません、

• 答え5:？

どう思いますか？前もって感謝します...

こんにちは、元の配列がいっぱいになったときに再割り当てしたいトリプルポインターがあります。何らかの理由で、私が realloc を使用している方法では、セグ フォールトが発生します。誰にも理由がありますか？

この次の部分は、ループ内で行われます。

ありがとう

私は多くの 2D int および float C 配列を作成しており、それらのポインターを NSPointerArray に割り当てようとしていました。それらを作成してデータを入力している間はすべて問題ありませんが、配列に addPointer を実行すると、EXEC_BAD_ACCESS が発生します。Q1-なぜこれが間違っているのですか？Q2-calloc で作成された多くの 2D 配列へのアクセスを提供する最善の方法は何ですか?

参考のため

}

文字列として表された数値を取得し、それらに対して加算操作を実行する必要があります。これは宿題のためであり、これまでに行ったことは一種の作業です。それは正しい出力を出力しますが、私のプログラムにはメモリエラーがない必要があり、それは確かにそうではありません.

これらの初期化されていない変数で何が起こっているかについて誰かが提供できるヘルプは役に立ちます。calloc の代わりに malloc を使用していると思いましたが、それも変更しましたが、サイコロはまだありません。

ここに私の出力があります：

これが私のコードです: /* * ファイル: strmath.c */

そして、これが私のvalgrind出力です（valgrindの完全な出力は 、SOには多すぎるため、 http: //textsnip.com/ae3c9aにあります）：

修理済み：

そして、valgrind の出力:

cmallcで割り当てられた符号なしポインタ配列を解放するための最良の方法は何ですか？

私はこれが好きですが、コンパイルの警告が表示されたので、これは正しくないことを知っています：

警告：「free」の引数1を渡すと、キャストなしで整数からポインタが作成されます

これがcs_callocコードです：

私の質問は1です。私が解放する方法、buf、つまり、ループ内の配列の各要素を最初に解放することを意味します（free（buf [i]）は正しいですか？配列の要素を解放する必要がありますか？その上

1. なぜそのコンパイル警告が表示されるのですか？それが間違っている場合は、割り当てられたメモリを解放する方法を誰かが修正できますか（修正方法のコードを教えてください）。

前もって感謝します

コードは次のようになります。

注： 上記のコードでは、DougLeaのmalloc.cdlcallocで定義されているコードを指します。

calloc中の前にfunc2()、

gPtr= "C：\ Program Files \ Test \ Path.txt"

calloc中に入った後func2()、

gPtr= "C：\ Program Files \Test\Path.txt♂"

私の質問は、連続したdlcalloc()呼び出しは他の変数のメモリを破壊する可能性がわずかにあるかということです。上記のコードは、私が取り組んでいるものの大きなコードベースの一部を一般化したものです。

fread()Cでファイルからメモリと配列データを割り当てる最も健全な方法は何だろうか.

まず、説明：

ここで、longBuffer を freading すると、コードは次のようになります。

2 つのうち、バージョン 1 はよりバグセーフであると言えます。なぜなら、 の型がlongBuffer変更された場合 (たとえば に)、を新しい型で更新するのint16_tを忘れることを心配する必要がないからです。fread()sizeof()

ここで、データの配列の場合、コードは次のように記述できます。

sizeof(<type>)ただし、これは最初の例で明らかになった問題を示しています。の型を変更するときに命令を同期することを忘れないように注意する必要がありcharpBufferます (たとえば、 からint8_t*へint16_t*)。

したがって、次のように書こうとするかもしれません。

よりバグセーフなバージョンとして。2行目の割り当ての後、書き込みcharpBuffer[0]は完全に有効になるため、これは機能するはずです。

また、次のように書くこともできます。

ただし、次のようなメモリ割り当てに対して同じことを試みます。

構文は優れていますが、未定義の動作を示します。これは、この段階でcharpBuffer[0]結果を書き込むと、NULL ポインターが逆参照されるためです。また、次のように書いています。

は同じ問題を示します。

だから、今の質問：

1. コードの「2b行目」と「3b行目」は正しいですか（この質問の未定義の動作は無視してください）、または「2a行目/3a行目」や「2行目」 /3"?

2. 「リスト 1」のコードを記述し、未定義の動作を回避する最もバグの少ない方法は何でしょうか?

編集（いくつかの側面を明確にするため）：

議論は間違った方向に進みました。コンパイル時間と実行時間の問題は 1 つの問題です (これについても標準的な保証が必要ですが、それはトピックではありません)。また、 sizeof(NULL dereferencing) の未定義の動作の問題は別のものです。コンパイル時であっても、これが標準によってUBにならないように保証されているとは確信していません。規格は何らかの保証を提供していますか?