fopen関数について

Question

実行環境：Windows XP（SP2）

開発環境：Visual C++6.0

 

はじめまして。質問させて頂きます。

ソフト開発を行っている方より耳にしたのですが、、、、、

「WindowsXPでfopen関数は使用しないほうがよい」

と教えられたのですが、本当なのでしょうか？

実際にfopenを使用したアプリをWindowsXP環境で繰り返し実施した際に強制終了が

発生したことがあり、CStdioFileｸﾗｽを使用して読み書きをすることで改善したとの事例もありました。

が、理屈が分からないので「なぜ？」と思ってしまいます。

（ちなみに、Windows2000では強制終了の発生はありませんでした）

 

fopen関数とWindows Xpとの関係を知っている方がいましたら、教えていただきたいと思います。

 

申し訳ありませんが、協力を宜しくお願いします。

Answer 1

ソフト開発を行っている方より耳にしたのですが、、、、、
「WindowsXPでfopen関数は使用しないほうがよい」
と教えられたのですが、本当なのでしょうか？

「なぜですか」とその人に聞いてみることが一番良いかと思われます。

---

質問スレッドで解決した場合は、解決の参考になった投稿に対して「回答としてマーク」のボタンを押すことで、同じ問題に遭遇した別のユーザが役立つ投稿を見つけやすくなります。

Answer 2

昔のWindows(ver1.0ver2.0)ではデータセグメントとスタックセグメントが異なるDLLなどで使用できるC言語の標準ライブラリが制限されていました。
しかし、もうそれは遠い過去の話（と思います）です。強制終了の原因を自分のコードに求めるべきでしょう。

---

Tomma

Answer 3

釈迦に説法かもしれませんが。

動いた、強制終了したという現象だけを捉えてこのプログラムは正常に動いていると判断するのは誤りです。

なぜなら「たまたま動いている状況」というのが実に普通に存在するからです。
Windows2000で動作しているのが、本当の意味で正常に動作しているのか、たまたま動いているのかは
現象だけを見て判断する事は出来ず、ソースコードを検証するなりして正常に動いていると思われると
言えるだけです。これすら厳密に言い出したら見落としの可能性は否定できません。

特にローカル変数に起因するメモリの不正アクセス系の不具合に関してはスタック上のメモリの状態に
左右される為、PCが変わっただけで動作状況が変わるなんて事もあります。

他の方が言われているように関数がどうのと言うよりもソース上に問題がある可能性の方が高いのではないかと思います。

Windows2000で実績があっても見落とされていた潜在バグの可能性は少なくないと思いますよ。

追記：この手のメモリがらみの不具合は単体テストや結合テストですら潜り抜けるケースがあります。
そういう意味ではテストを繰り返したとしてもバグが０であるという事の証明にはなりません。
テストしたケースに関しては仕様通りの動作が確認されていると言うのが正確な表現になります。

現実問題として潜在バグも含めて全てのバグを完全に排除したと言うのはとても難しい事です。
プログラムの規模が大きくなればなるほどその可能性は大きくなります。
我々にできるのはテストパターンやテスト環境を複数そろえてバグを補足する可能性を上げる事くらいしか出来ません。
とはいえ、きちんとテストしていれば正常に動く可能性はかなり高くなりますし、運用上問題がない状態にはできるはずです。

もっとも最近は静的解析ツール等でソース上の不具合と思しき部分を実行せずに確認できるようになって来ているので潜在バグになる前につぶす事もかなりできるようになっているとは思います。

---

解決した時は、参考になったレスポンスの所にある［回答としてマーク］ボタンをクリックしてスレッドを締めましょう。

Answer 4

16bit版のWindowsでは、fopen()に限らず、C言語の標準ライブラリのかなりの部分が
使えませんでした。中でも標準関数のsprintf()が使えないのはとっても痛く、
代替のSDKの関数、wsprintf()は使えるフォーマット文字列が、やや制限されて
いたため、往生したもんです(とほい目)。

現在の32bit(以上)版Windowsでは標準ライブラリは正しく動作します。
この朗報を聞いたときは小躍りして喜んだもんです。

ですが、OSの文字コードが標準でUnicodeになってしまったため、charや
char *を使用するほとんどの標準関数は、やや利用価値が下がってしまいました。