危険だというtmpnamの警告
Tmpnamは危険だという警告が表示されますが、WindowsだけでなくLinuxでもそのまま使用できるので、使用したいと思います。なぜ危険だと思われるのだろうと思っていました（実際には正しく機能しないのではなく、誤用の可能性があるためだと思います）。
Tmpnamのマンページから：
Tmpnam（）関数は、呼び出されるたびに、最大TMP_MAX回まで異なる文字列を生成します。 TMP_MAX回を超えて呼び出された場合、動作は実装によって定義されます。
Tmpnam（）は推測が難しい名前を生成しますが、それでも、tmpnam（）がパス名を返す時間とプログラムがパス名を開く時間の間に、別のプログラムがopen（2）を使用してそのパス名を作成する可能性があります。シンボリックリンクとして作成します。これはセキュリティホールにつながる可能性があります。このような可能性を回避するには、open（2）O_EXCLフラグを使用してパス名を開きます。または、mkstemp（3）またはtmpfile（3）を使用することをお勧めします。
Mktempは実際にファイルを作成するので、確実に機能しますが、tmpnamは、おそらく既存の名前を返します。
複数のプラットフォームで同じシンボルを使用する場合は、マクロを使用してTMPNAMを定義します。同じインターフェースでより安全な機能を選択する限り、両方でそれを使用することができます。とにかく、コードのどこかに条件付きコンパイルがありますよね？
Tmpnam（3）のマンページから：
Tmpnam（）は推測が難しい名前を生成しますが、それでもtmpnam（）がパス名を返す時間とプログラムがパス名を開く時間の間に、別のプログラムがopen（2）を使用してそのパス名を作成する可能性があります。 、またはシンボリックリンクとして作成します。これはセキュリティホールにつながる可能性があります。このような可能性を回避するには、open（2）O_EXCLフラグを使用してパス名を開きます。または、mkstemp（3）またはtmpfile（3）を使用することをお勧めします。
mSVCのコンパイラ警告について話す場合：
These functions are deprecated because more secure versions are available;
see tmpnam_s, _wtmpnam_s.
（ http://msdn.Microsoft.com/de-de/library/hs3e7355（VS.80）.aspx ）
それ以外の場合は、この関数の欠点についてマンページに記載されている内容を読んでください。これは主に、プロセスが行ったのとまったく同じファイル名を作成する2番目のプロセスに関するものです。
tmpnam()がそのバッファに書き込む文字列を処理するのに十分な大きさのバッファを割り当てる必要があるため、この関数は危険です。小さすぎるバッファを割り当てると、tmpnam()はそれを知る方法がなく、バッファをオーバーランします（大混乱を引き起こします）。 tmpnam_s()（MSのセキュアバージョン）では、バッファの長さを渡す必要があるため、tmpnam_sいつ停止するかを知っています。