同一个C程序在linux和win下表现不一致

[john]

一个C语言编写的PCM音频编码/解码程序，仅仅使用的C的函数，没有使用任何与OS特别相关联的特别函数。在Linux下（用cc或gcc）编译、执行均正确无误。在win下用Dev-C++编译无误，但执行结果确不正确。
请问：在同样的CPU平台下，Linux的C语言，与Win下的Dev-C++环境的C语言，在语言的定义上，（例如标准类型的长度，数据存储的顺序等方面）是否有所不同？

[once_and_again]

顺序点. 副作用.

[nullah]

学习...
MARK

[john]

因为用了浮点和双精度类型。怀疑在这方面有所不同。

[john]

有一中观点说：字节保存顺序也会不同 。 不能确定这个说法是正确的。

[john]

也怀疑在：“函数带有运算的参数”这一点上，可能是有所不同的。

[john]

在VC6下，程序也编译通过，运行也同DEV-C++一样。运行结果不对（程序异常终止）。
谢谢“once_and_again”的提醒。“once_and_again”可否再多说几个字？

[qap22]

ding

[invaliddescriptor]

ding

[john]

目前的最新进展报告给大家，供大家批评指正，因为这个现象如果普遍存在，确实是个问题。
在WIN2K下调试结果如下：
Visual C++ Debug 执行时，程序弹出:
Unhandled exception in Project1.exe:0xC0000005:Access Violation
Debug窗口提示是：
....
HEAP[Project1.exe]: Invalid allocation size - f3333360 (exceeded 7ffdefff)
First-chance exception in Project1.exe: 0xC0000005: Access Violation.
....

Dev-C++ Debug执行时，程序弹出:
Warning
An Access Violation (Segmentation Fault) raised in your program

问题都指向了这个函数：
addwvec(length, nvec, weight, vec, out)
int length, nvec;
double *weight, *vec, *out;
{

int k, j;
for (k = 0; k < length; ++k)
out[k] = *weight * *vec++;


for (j = 1; j < nvec; ++j) {
++weight;
for (k = 0; k < length; ++k)
out[k] += *weight * *vec++;
}
return;
}
现在的问题反而成了，这样一个函数为何能在Linux下正确的执行？

[john]

怀疑：
类型的缺省长度不同。
运算符号的缺省优先级处理不同。
缺省的预先分配内存不同。
对C的副作用，处理上有所不同。

[tobylee999]

呵，N年前遇到过这种情况，不是文本永远不要用TXT去操作～

DEV计算精度比VC好？学习了～

[threeleafzerg007]

[Quote=引用 13 楼 JohnPhan 的回复:]
UNIX文件不区分text & binary，处理时候不用计较文件类型。
WIN则text & binary“很计较”。故在WIN下用text读&写“数值”，则全乱了套了。

读出的数值不对，以此去分配内存，自然不对了。

另外发现一个副产品：
这个语音压缩&解码程序，用VC，声音还原不符合要求，结果很难听。用DEV，结果声音好听且符合要求。
同一个程序，结果咋就那么大呢？原因是VC的计算精度太差了。 当然调试方便，一俊遮百丑。
[/Quote]

的确，Unix所有输入文件都当作字节流处理，Windows 区分字节流 还是 二进制(最好用 fread fwrite)，顶一下！

[john]

问题解决了。是它们读写文件不同。

[hhyttppd]

up,接分

HEAP[Project1.exe]: Invalid allocation size - f3333360 (exceeded 7ffdefff)
First-chance exception in Project1.exe: 0xC0000005: Access Violation.
呵呵，我怎么觉得是new的尺寸太大了啊，这个应该编译的时候就报错，不会等到执行。

[john]

UNIX文件不区分text & binary，处理时候不用计较文件类型。
WIN则text & binary“很计较”。故在WIN下用text读&写“数值”，则全乱了套了。

读出的数值不对，以此去分配内存，自然不对了。

另外发现一个副产品：
这个语音压缩&解码程序，用VC，声音还原不符合要求，结果很难听。用DEV，结果声音好听且符合要求。
同一个程序，结果咋就那么大呢？原因是VC的计算精度太差了。 当然调试方便，一俊遮百丑。

[xtdumpling]

o,学习

[john]

程序中使用的类型主要是double。将程序在：
Soalris gcc
Ubuntu（linux）gcc
WIN DEV C++
WIN VC6
运行主观比较：前三者还原出的声音正常。VC6声音失真比较严重。
具体误差在那个细节上，没有功夫搞了。
intel C++ 没有测试。

[smallqiang0]

ding...

[smallqiang0]

ding...