由于我是原生的FORTRAN程序员，因此我提前道歉。 我得到了一些c代码来debugging哪个摄取二进制文件，并将其parsing为一个input文件，该文件包含我正在使用的一个Fortran程序的几百条logging（确切地说就是871条logging）。 问题是这些input二进制文件和相关的c代码是在Windows环境中创build的。 parsing器读取二进制文件，直到达到文件末尾：
SAGE_Lvl0_Packet GetNextPacket() { int i; SAGE_Lvl0_Packet inpkt; WORD rdbuf[128]; memset(rdbuf,0,sizeof(rdbuf)); fprintf(stdout,"Nbytes: %u\n",Nbytes);//returns 224 if((i = fread(rdbuf,Nbytes,1,Fp)) != 1) FileEnd = 1; else { if(FileType == 0) memcpy(&(inpkt.CCSDS),rdbuf,Nbytes); else memcpy(&inpkt,rdbuf,Nbytes); memcpy(&CurrentPacket,&inpkt,sizeof(inpkt)); } return inpkt; } 所以当代码到达数据包872时，这段代码应该返回FileEnd = 1.相反，parsing器试图从文件末尾（接近）读取大量数据。 我认为这会导致程序崩溃（至less在Fortran中会出现这种情况，是不是刚刚开始读取下一部分的内存？）幸运的是，在后面的代码中有一个CRC表示parsing器不是“读取正确的数据并优雅地退出。
我认为这个问题源于Windows二进制文件中的二进制缓冲区大小和值比Linux中的更大/不同。 如果是这样的话，有没有一种简单的方法将Windows的二进制文件转换为Linux或Linux？ 如果我错了，那么也许我需要再看一遍这个代码。 顺便说一句，WORD是一个无符号短整型，而SAGE_Lvl0_Packet是一个三层结构，总共有106个WORD。
我认为这里最大的问题是，当fread()指示文件结束时， FileEnd标志被设置，但函数仍然返回一个（无效的）归零数据包。 不是一个特别强大的设计。 我假设调用者应该检查FileEnd然后再尝试使用刚刚返回的数据包，但由于没有显示，所以很可能是一个错误的假设。
另外，不知道数据包是什么样的，不可能知道各种memcpy()调用是否正确。 memcpy()被要求复制224个字节到一个据说只有212个字节的结构的事实是非常有问题的。
可能还有其他问题，但目前我看到的是大问题。