c - 在 Intel X_86 和 ARM 架构上转储两个相邻的 C 数组时出现奇怪的不同结果

标签 c arrays raspberry-pi arm

在下面两种不同的计算机体系结构中,使用 C 转储相同的两个数组时,我得到两个不同的结果。谁能给我解释一下原因吗?

  1. 架构一:x86_64(普通 64 位 intel PC,fedora 23)

  2. 架构二:armv7l(带有 raspbian 的树莓派)

这是示例代码

double ytops[7];
double ybots[7];                     

// Assigning values loop
for(int i=0;i<8;i++)
{
    frame_grabber(); // some custom function that gives sensor data with two variables: ruler_top_cal_preset, ruler_bottom_cal_preset integer

    ytops[i] = ruler_top_cal_preset;
    ybots[i] = ruler_bottom_cal_preset;

    printf("ytops[%i]: %f \n", i, ytops[i]);
    printf("ybots[%i]: %f \n", i, ybots[i]);
}

printf("---raw-array--- \n");

for(int i = 0; i<8; i++ ){ 
     printf("ytops[%i]: %f \n", i, ytops[i]);
}

printf("--------------- \n");

for(int i = 0; i<8; i++ ){ 
     printf("ybots[%i]: %f \n", i, ybots[i]);
}

printf("-------end----- \n");

架构 1(X_86) 给出以下结果:

ytops[0]: 143.000000 
ybots[0]: 211.000000 
ytops[1]: 143.000000 
ybots[1]: 211.000000 
ytops[2]: 143.000000 
ybots[2]: 175.000000 
ytops[3]: 144.000000 
ybots[3]: 175.000000 
ytops[4]: 144.000000 
ybots[4]: 175.000000 
ytops[5]: 144.000000 
ybots[5]: 175.000000 
ytops[6]: 144.000000 
ybots[6]: 172.000000 
ytops[7]: 143.000000 
ybots[7]: 172.000000 
---raw-array--- 
ytops[0]: 143.000000 
ytops[1]: 143.000000 
ytops[2]: 143.000000 
ytops[3]: 144.000000 
ytops[4]: 144.000000 
ytops[5]: 144.000000 
ytops[6]: 144.000000 
ytops[7]: 143.000000 
--------------- 
ybots[0]: 211.000000 
ybots[1]: 211.000000 
ybots[2]: 175.000000 
ybots[3]: 175.000000 
ybots[4]: 175.000000 
ybots[5]: 175.000000 
ybots[6]: 172.000000 
ybots[7]: 172.000000 
-------end----- 

架构 2 (ARMV7l) 给出:

ytops[0]: 206.000000
ybots[0]: 413.000000
ytops[1]: 206.000000
ybots[1]: 411.000000
ytops[2]: 205.000000
ybots[2]: 427.000000
ytops[3]: 206.000000
ybots[3]: 415.000000
ytops[4]: 205.000000
ybots[4]: 416.000000
ytops[5]: 205.000000
ybots[5]: 421.000000
ytops[6]: 206.000000
ybots[6]: 411.000000
ytops[7]: 206.000000
ybots[7]: 418.000000
---raw-array---
ytops[0]: 418.000000
ytops[1]: 206.000000
ytops[2]: 205.000000
ytops[3]: 206.000000
ytops[4]: 205.000000
ytops[5]: 205.000000
ytops[6]: 206.000000
ytops[7]: 206.000000
---------------
ybots[0]: 413.000000
ybots[1]: 411.000000
ybots[2]: 427.000000
ybots[3]: 415.000000
ybots[4]: 416.000000
ybots[5]: 421.000000
ybots[6]: 411.000000
ybots[7]: 418.000000
-------end-----

当然,由于该运动时的传感器数据,比较两个结果集时的数值是不同的。可以接受。

在架构一上,一切都是由值分配循环分配的。这是正确的。但是,请查看“赋值循环”中架构二的结果集“ytops[0]”值以及“原始数组”打印的相同值。

ytops[0] 正在获取 ybots[7]

的值

这怎么可能?这种现象叫什么?如何避免这种情况?

最佳答案

你所有的都是错的。

使用数组索引从 0length_of_array-1

所以,使用

for(int i=0;i<8;i++)

由于最后一个 i 值为 7,您正在越界访问数组:您的数组从 ytops[0] 开始到ytops[6]。这是Undefined Behavior

您必须使用

for(int i=0;i<7;i++)

如果你这样做的话最好,例如使用ytops数组

for(size_t i=0;i<sizeof(ytops)/sizeof(ytops[0]);i++)

关于c - 在 Intel X_86 和 ARM 架构上转储两个相邻的 C 数组时出现奇怪的不同结果,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/38735710/

相关文章:

python - 如何通过 BLE 将数据从 Raspberry Pi 3 python 文件发送到手机?

c++ - 如果产品太大而无法代表,该如何计算?

java - Weblogic 12c粘性问题

c++ - 编译成可执行文件

c - 被 pthread_cond_signal() 唤醒但失去对互斥锁竞争的线程会发生什么

java - 可以单独访问的多个线程

arrays - 使用 Perl 在目录中创建文件数组时处理隐藏文件

python - 根据颜色值将多维 Numpy 数组转换为二维数组

c++ - GCC 中树莓派的交叉编译。从哪儿开始?

c++ - 在 QString 插入函数中使用参数