strcpyの代わりにstrncpyを使用する必要があるのはなぜですか？

編集：例のソースを追加しました。

私はこの例に出くわしました：

char source[MAX] = "123456789";
char source1[MAX] = "123456789";
char destination[MAX] = "abcdefg";
char destination1[MAX] = "abcdefg";
char *return_string;
int index = 5;

/* This is how strcpy works */
printf("destination is originally = '%s'\n", destination);
return_string = strcpy(destination, source);
printf("after strcpy, dest becomes '%s'\n\n", destination);

/* This is how strncpy works */
printf( "destination1 is originally = '%s'\n", destination1 );
return_string = strncpy( destination1, source1, index );
printf( "After strncpy, destination1 becomes '%s'\n", destination1 );

この出力を生成したもの：

宛先は元々= 'abcdefg'
strcpyの後、宛先は「123456789」になります

destination1は元々= 'abcdefg'
strncpyの後、destination1は「12345fg」になります

なぜ誰もがこの効果を望んでいるのだろうと私は思います。紛らわしいようです。このプログラムは、基本的に誰かの名前（Tom Brokawなど）をTomBro763でコピーできると思います。

使用しての利点は何である strncpy() 以上は strcpy()？

strncpyバッファオーバーフローに長さを入力するように要求することで、バッファオーバーフローと戦います。strcpy末尾\0に依存しますが、常に発生するとは限りません。

次に、7文字の文字列に5文字だけをコピーすることを選択した理由は私にはわかりませんが、期待どおりの動作が得られます。最初のn文字をコピーするだけnです。ここで、は3番目の引数です。

これらのn関数はすべて、バッファオーバーフローに対する防御コーディングとして使用されます。などの古い関数の代わりに使用してくださいstrcpy。

このstrncpy()関数は、元のUNIXディレクトリエントリの方法で保存された文字列を操作するという非常に特別な問題を念頭に置いて設計されました。これらは固定サイズの配列を使用し、nul-terminatorはファイル名が配列よりも短い場合にのみ使用されました。

それが2つの奇妙なことの背後にあるものですstrncpy()：

• 完全にいっぱいになった場合、宛先にヌルターミネータを配置しません。そして
• 常に目的地を完全に埋め、必要に応じてヌルで埋めます。

「より安全」なstrcpy()場合は、次のstrncat()ように使用することをお勧めします。

if (dest_size > 0)
{
    dest[0] = '\0';
    strncat(dest, source, dest_size - 1);
}

これにより、結果は常にnullで終了し、必要以上にコピーされることはありません。

私はその背後strncpyにある意図を知っていますが、それは本当に良い機能ではありません。両方を避けてください。レイモンドチェンは説明します。

個人的には、strncpynullで終了する文字列を扱っている場合、私の結論は単に回避することです。名前に「str」が含まれているにもかかわらず、これらの関数はnullで終了する文字列を生成しません。ヌル文字で終了する文字列を生の文字バッファに変換します。2番目のバッファが明らかに間違っているため、nullで終了する文字列が予想される場合にそれらを使用します。ソースが長すぎると適切なnull終了が得られないだけでなく、ソースが短すぎると不要なnullパディングが発生します。

strncpyが安全でない理由も参照してください。

strncpyはstrcpyより安全ではなく、あるタイプのバグを別のタイプのバグと交換するだけです。Cでは、C文字列を処理するときに、バッファのサイズを知る必要があります。それを回避する方法はありません。strncpyは、他の人が言及したディレクトリのことで正当化されましたが、それ以外の場合は、決して使用しないでください。

• 文字列とバッファの長さがわかっている場合、なぜstrncpyを使用するのですか？せいぜい計算能力の無駄です（無駄な0を追加）
• 長さがわからない場合は、文字列を黙って切り捨てるリスクがあります。これは、バッファオーバーフローよりもはるかに優れているわけではありません。

あなたが探しているのは、strlcpy()常に文字列を0で終了し、バッファを初期化する関数です。また、オーバーフローを検出することもできます。唯一の問題は、（実際には）移植性がなく、一部のシステム（BSD、Solaris）にのみ存在することです。この関数の問題は、http：//en.wikipedia.org/wiki/Strlcpyでの議論からわかるように、ワームの別の缶を開くことです 。

私の個人的な意見は、それがより大幅により有用であるということであるstrncpy()とstrcpy()。パフォーマンスが向上し、の優れたコンパニオンsnprintf()です。それを持たないプラットフォームの場合、実装は比較的簡単です。（アプリケーションの開発フェーズでは、これら2つの関数（snprintf()およびstrlcpy()）を、バッファオーバーフローまたは切り捨てでプログラムを残酷に中止するトラップバージョンに置き換えます。これにより、最悪の違反者をすばやくキャッチできます。特に、他の誰かのコードベースで作業している場合。

編集：strlcpy()簡単に実装できます：

size_t strlcpy(char *dst, const char *src, size_t dstsize)
{
  size_t len = strlen(src);
  if(dstsize) {
    size_t bl = (len < dstsize-1 ? len : dstsize-1);
    ((char*)memcpy(dst, src, bl))[bl] = 0;
  }
  return len;
}

このstrncpy()関数はより安全です。宛先バッファーが受け入れることができる最大長を渡す必要があります。そうしないと、ソース文字列が正しく終了しない可能性があります。その場合、strcpy()関数は宛先にさらに文字を書き込み、宛先バッファの後にメモリ内にあるものをすべて破壊する可能性があります。これは、多くのエクスプロイトで使用されるバッファオーバーランの問題です。

またread()、終了0をバッファーに入れず、読み取ったバイト数を返すようなPOSIX API関数の場合は、手動で0を入れるか、を使用してコピーしstrncpy()ます。

サンプルコードでindexは、は実際にはインデックスではありませんが、count-ソースから宛先にコピーする最大文字数を示します。ソースの最初のnバイトの中にヌルバイトがない場合、宛先に配置された文字列はヌル終了されません

strncpyは、宛先のサイズが小さい場合でも、ソースのサイズとして宛先を「\ 0」で埋めます。

マンページ：

srcの長さがn未満の場合、strncpy（）はdestの残りの部分をnullバイトで埋めます。

そして残りだけでなく...この後もn文字に達するまで。したがって、オーバーフローが発生します...（manページの実装を参照）

これは、元の文字列の一部のみをコピー先にコピーする必要がある他の多くのシナリオで使用できます。strncpy（）を使用すると、strcpy（）とは対照的に、元の文字列の限られた部分をコピーできます。あなたが作成したコードはpublib.boulder.ibm.comからのものだと思います。

それは私たちの要件に依存します。Windowsユーザー向け

文字列全体をコピーしたくない場合、またはn個の文字のみをコピーしたい場合は、strncpyを使用します。ただし、strcpyは、終端のnull文字を含む文字列全体をコピーします。

これらのリンクは、strcpyとstrncpyについて、そしてどこで使用できるかを知るのに役立ちます。

strcpyについて

strncpyについて

strncpyはstrcpyのより安全なバージョンです。実際のところ、strcpyを使用しないでください。これは、潜在的なバッファオーバーフローの脆弱性により、システムがあらゆる種類の攻撃に対して脆弱になるためです。