C言語がfwriteしたintのサイズがおかしい？

Question

###実現したいこと
C言語がfwriteしたintをNode.jsで読みたい。

###発生している問題
次のコードを見てください。
C言語がintの「789129」をfwriteしています。

int main(){
	FILE* fp = fopen("hoge.dat", "w");
	int num = 789129;
	fwrite(&num, sizeof(int), 1, fp);
	fclose(fp);
}

このプログラムを実行して得られたhoge.datをバイナリエディタで見ると、次のようになっていました。

      00010203 04050607 08090A0B 0C0D0E0F
0000  890D0A0C 00

私の処理系では、sizeof(int)は4(32bit)を返します。
それなのに、ファイルには5バイトのデータが書き込まれています。
この数値を、例えばNode.jsのreadInt32LEを使って読もうとすると、当然おかしな数値が返ってきてしまいます。
諸事情により、C言語側のプログラムを修正することは出来ません。
何故5バイトのデータが書かれてしまうのか、またどのようにすればNode.jsでこのデータを解釈できるのか。
教えてほしいです。

####補足
この問題は常に起こるわけでは無いようです。
例えば「7891290」を先程のCのプログラムでfwriteしてみると、

      00010203 04050607 08090A0B 0C0D0E0F
0000  5A697800

のようになっており、4バイトのデータが書き込まれています。
これはリトルエンディアンの32bitIntで「7891290」ですから、readInt32LEで読めるのですが…。

####Cのコンパイル環境
Win10(x64)で、gcc4.8.1を使っています。

Answer 1

fopen("hoge.dat", "w")(テキストモード)ではなくfopen("hoge.dat", "wb");(バイナリモード)とすべきです。

Windows環境のテキストモードでは、LF(\n)/0x0A は CR+LF(\r+\n)/0x0D+0x0A という2バイトへと変換されてしまいます。バイナリデータを出力するときは、バイナリモードの指定は必須です。C言語プログラムとしての致命的なバグですから、原則としてC言語プログラム側を修正すべきです。

---

しかし、今回のケースではCのプログラムには変更を加えられません。
このソースで書かれたデータをNode.jsが解釈する方法はありますか？

残念ながら、Node.js側で正しく復号(解釈)するのはおそらく不可能です。

復号処理は「バイト並び0x0D+0x0Aを0x0Aへと戻す」のですが、正しいオリジナルデータの時点で0x0D+0x0Aの場合も誤って0x0Aへと逆変換してしまいます。言い換えると、ファイルに0x0D+0x0Aバイト並びがあったとき、それがオリジナルの0x0D+0x0Aという2バイトだったのか、0x0Aという1バイトだったのかを判断する手段がありません。何らかの仮定やデータ範囲の制約条件を置けるならば、復号できる可能性があるかもしれませんが...

Comments

[triv0602]

ありがとうございます。
ちゃんとreadInt32LEで読めました。
しかし、今回のケースではCのプログラムには変更を加えられません。
このソースで書かれたデータをNode.jsが解釈する方法はありますか？

Answer 2

こんにちは。

これはWindows特有の問題です。テキスト・モードてオープンしたファイルへ改行コードを出力するとCRLFへ変換されてしまいます。今回はLF(0x0A)を出力したらCRLF(0x0D, 0x0A)へ変換されたケースですね。
他にも何か自動変換があるかもしれませんが、良く分かりません。

他になければ、バイナリの状態で0x0D, 0x0Aを検出したら0x0Aへ変換してから、数値へデコードすればできる筈です。でも、かなり無理矢理なので何か思わぬ不具合ができるかもです。C側を変えるのが「まっとう」なやりかたです。

後、もしも、リビルドできるのでしたら、bash on windows上で走らせるとか。
linuxはテキスト・モードとバイナリ・モードの差はなかった筈ですので、このような変換はされないと思います。
でも、bash on windowsはまだβですし、いろいろ問題を抱えているようですので、あまりお勧めできません。

思い出しました。API Hookするなんて無茶もあります。
MinGW(gcc)のfopenは恐らくCreatFileA()を呼び出していると思います。
CreateFileA()をすげ替えて、ファイル名で問題の呼び出しかどうか判定し、問題の呼び出しならテキスト・モードからバイナリ・モードへすげ替える、そうでないときはCreateFileA()へパススルーすることでやってやれないことはないかも知れません。

Comments

[triv0602]

ありがとうございます。「バイナリの状態で0x0D, 0x0Aを検出したら0x0Aへ変換」することにします。
「bash on windows上で走らせる」
「API Hook」
すみません。Cのプログラムはexeにコンパイルされていて、修正が難しいということを書いておくべきでした…。
上記の方法で無事に解決できました。
ありがとうございました。

Answer 3

自分の環境はWindows10 cygwin(64bit) gcc (GCC) 5.4.0ですが、こういったことは発生しませんでした。つまりLinuxと同様に改行コードLFがCR,LFに置き換わって出力されるということはやってないようです。想像するにcyginはMinGWよりUnixライクな環境をエミュレートしているということなのかと思います。もしそうならこれはMinGW固有の振る舞いということなのかも知れないと思いました。

どのようにすればNode.jsでこのデータを解釈できるのか

本来はyohhoyさんがおっしゃるようにソースを直せればよいのですが、無理ということなので回避策を考えてみると・・・

おそらくはfwriteの振る舞いはNL(0x0A)->CR,NL(0x0D,0x0A)へ変換するだけだと思います(念のため0x00～0xFFまで実際にfwriteの結果がどうなるか確認すべきかと思います)が、もしそうなら結果のファイルの中の0x0Aというバイトは0x0Dの直後にしか存在しないはずです。よってreadInt8を使って1バイトずつ読みながら0x0D,0x0Aのシーケンスを見つけたらそれを0x0Aと解釈する方法で元のバイト列が回復できると思います。そのようにして4バイト分を読み込んだらそれを(リトルエンディアンを意識しつつ)intへ変換してやれば元のデータが再現できます。この処理を関数として自前で定義してそれをreadInt32LEの代わりに用いることで回避策になると思います。

やむをえないとはいえこういった回避策はおっかないですね。メンテナンスにえらく神経を使わなければいけなさそうなので・・・

Comments

[triv0602]

ありがとうございます。
cyginでは挙動が違うのですね。勉強になります。
ご指摘の回避策でなんとか動いている状況です。怖いですね。