fwrite在linux和win10上的不一致

作为芯片原厂，经常会提供些代码例程，配合文档给客户参考，让客户可以直接在PC上运行，方便他们了解细节和移植。

直接给代码，而不能运行的，在客户遇到问题的时候，缺少参照。在PC上可以方便运行的话，那么客户在其它平台移植的时候，就很容易对比数据，判断出问题出在哪里了。而且，我们也容易证明，给出去的代码是完整的，正确的。

 

我们的代码都是在linux平台跑的。客户基本都使用windows平台。那么我们必须要转化为win10可跑的形式。这样才能便利。我们的例子都使用gcc开发，那么要能够最小改动并在win10上跑，就是在win10上安装个gcc的环境即可。考虑简单，我这里使用了TDM-GCC。下载和安装，一步到位。

        把原来linux的例程，简单的修改了下makefile，就欢快的在win10上编译通过了。很顺利啊，总感觉不可能那么简单！果然，运行的时候，数据输出怪怪的。看代码逻辑吧，肯定没有问题。那么我就想，也许出现了某些API在linux和win10行为不一致的情况。

        跟踪发现我使用了fwrite，在linux上每次写数据，都可以完整的写进去。但是这个函数，在win10上，只能写一半的数据。为什么呢？原来win10默认的open方式是按照文本的方式打开文件的，所以读写数据的时候，会按照文本的方式进行，写数据的时候会判断数据里是否有结束符，换行什么的。我是要处理2进制的数据流，不希望按照字符文字的方式处理。

        linux上这样使用：fopen(path_buffer, "wb")，没有问题，因为它统一按照2进制流处理。但是在windows上，必须这样：fopen(path_buffer, "wb+")才能和linux的行为保持一致。

        多了解一些平台的区别，尽量不使用默认的行为，也许是个更好的办法来避免这样的问题。