我有一个转换的ASCII字符串双用的strtod（...）的一些C代码。 该程序被编译为86（调试），ARM和PowerPC（嵌入式目标系统）。 在ARM板实际上是一个BeagleBoard的XM运行Debian的是为它提供。
我发现，关于strtod（）不正确地转换ARM / Debian系统上的值。 事实上，我尝试了所有的值来如0.000。
为了证明，我写了下面很简单的测试程序：
#include <stdio.h>
#include <stdlib.h>
int main(const int argc, const char **argv)
{
const char myString[] = "123 ";
char *myEnd1 = NULL;
char *myEnd2 = NULL;
float fValue = 0;
double dValue = 0;
dValue = atof(myString);
printf( "Using atof():\n"
" String: %s\n"
" Double: %lf\n",
myString,
dValue );
fValue = strtof(myString, &myEnd1);
dValue = strtod(myString, &myEnd2);
printf( "Using strtof() / strtod():\n"
" String: %s\n"
" Float: %f (%d)\n"
" Double: %lf (%d)\n",
myString,
fValue, (myEnd1 - myString),
dValue, (myEnd2 - myString) );
return 0;
}
所有汇编（在虚拟机实际上）运行Ubuntu在x86 PC上。 我对PowerPC和ARM汇编交叉编译工具链。
在x86和PowerPC系统，如预期的输出，即：
Using atof():
String: 123
Double: 123.000000
Using strtof() / strtod():
String: 123
Float: 123.000000 (3)
Double: 123.000000 (3)
然而，当上了BeagleBoard的运行，我得到这样的：
Using atof():
String: 123
Double: 0.000000
Using strtof() / strtod():
String: 123
Float: -0.372039 (3)
Double: 0.000000 (3)
咦??? 我错过了什么傻？ 请注意，“myEnd”指针只是有证明的strtod（）和strtof（）没有找到的第一个非数字字符，因此号的末尾。 他们报告正确的字符数量在这两种情况下（3）的数量，但转换后的值是错误的。 我不认为这是一个语言环境的问题，因为没有小数点弄不清楚。
编辑：
我只是选项“-static”重新编译测试程序。 这使得二进制大得多，当然，但现在它正常工作的目标ARM平台上。
我在图书馆的工作方式有点朦胧。 另外，我不记得到底我建立了我的交叉编译工具链。 它作为Debian的Linux的目标板上实际安装可能不是来自同一个源代码构建。
那么，这是否ATOF（），等的无法解释的行为，是指一库“预期”，由动态链接的可执行文件是不一样的系统上的实际库？ 我很惊讶，这并没有造成更严重的问题。 我们已经运行这个系统了一年，到目前为止，这是我们遇到的唯一奇怪的错误。
