为什么32位编译器和64位编译器会对我的代码产生如此大的影响？[重复]
请原谅我英语不好。
我写了一些行来返回最大值、最小值、所有值之和，并在输入五个整数时按升序排列所有值。
在编写时，当我需要输入5个整数时，在声明一个INT数组时，我错误地编写了'num[4]'。但当我使用TDM-GCC4.9.2 64位版本编译时，它运行起来没有任何问题。当我意识到并更改为TDM-GCC 4.9.2 32位版本时，它没有。
这是我的全部代码；
#include<stdio.h>
int main()
{
int num[4],i,j,k,a,b,c,m,number,sum=0;
printf("This program returns max, min, sum of all values, and arranges all values in ascending order when five integers are input.\n");
printf("Please enter five integers.\n");
for(i=0;i<5;i++)
{
printf("Enter #%d\n",i+1);
scanf("%d",&num[i]);
}
//arrange all values
for(j=0;j<5;j++)
{
for(k=j+1;k<5;k++)
{
if(num[j]>num[k])
{
number=num[j];
num[j]=num[k];
num[k]=number;
}
}
}
//find maximum value
int max=num[0];
for(a=1;a<5;a++)
{
if(max<num[a])
{
max=num[a];
}
}
//find minimum value
int min=num[0];
for(b=1;b<5;b++)
{
if(min>num[b])
{
min=num[b];
}
}
//find sum of all values
for(c=0;c<5;c++)
{
sum=sum+num[c];
}
printf("Max Value : %d\n",max);//print max
printf("Min Value : %d\n",min);//print min
printf("Sum : %d\n",sum); //print sum
printf("In ascending order : "); //print all values in ascending order
for(m=0;m<5;m++)
{
printf("%d ",num[m]);
}
}
我不熟悉C和各种编程，不知道如何搜索这些问题。我知道我在这里这样提问是非常不合适的，我真诚地向那些被这些提问帖子激怒的人道歉。但这是我最好的尝试，所以请不要责怪，但我愿意接受任何建议或提示。
谢谢你。
共有2个答案
其他答案通过分析生成的程序集涵盖了他实际可能发生的事情，但真正相关的解释是：在C中，索引数组边界是未定义的行为。这就是故事的结尾。
UB的意思是，根据C标准，代码“允许”做任何事情。每次运行时，它可以做不同的事情。它可以做你想做的事情，而不会产生不良影响。它可能会做你想做的事情，但之后一些完全不相关的事情会以一种有趣的方式发生。编译器、操作系统，甚至月球的相位都可能产生影响。或者不是。
在C级，考虑未定义行为的实际情况通常是没有用的。当然，您可以生成特定编译的程序集输出，并检查它的功能，但这是该编译的结果。一个新的编译可能会改变一些事情（即使你只是在不同的时间进行新的构建，因为\uuuuuuuuuuuuuuuuuuuu宏的值取决于时间…）。
在堆栈上进行分配时，以64位（可能还有Clang）为目标的GCC会将堆栈分配调整为8字节。
对于32位目标，它只需要使用4字节的填充。
因此，当您编译64位的程序时，额外的四个字节用于填充堆栈。这就是为什么当你访问最后一个整数时，它没有出错。
要查看此操作，我们将创建一个测试文件。
void test_func() {
int n[4];
int b = 11;
for (int i = 0; i < 4; i++) {
n[i] = b;
}
}
我们将编译32位和64位。
gcc -g -c -m64 test.c -o test_64.o
gcc -g -c -m32 test.c -o test_32.o
现在我们将打印每个的拆解。
objdump -S test_64.o >test_64_dis.txt
objdump -S test_32.o >test_32_dis.txt
以下是64位版本的内容。
test_64.o: file format elf64-x86-64
Disassembly of section .text:
0000000000000000 <func>:
void func() {
0: f3 0f 1e fa endbr64
4: 55 push %rbp
5: 48 89 e5 mov %rsp,%rbp
8: 48 83 ec 30 sub $0x30,%rsp
c: 64 48 8b 04 25 28 00 mov %fs:0x28,%rax
13: 00 00
15: 48 89 45 f8 mov %rax,-0x8(%rbp)
19: 31 c0 xor %eax,%eax
int n[4];
int b = 11;
1b: c7 45 dc 0b 00 00 00 movl $0xb,-0x24(%rbp)
for (int i = 0; i < 4; i++) {
22: c7 45 d8 00 00 00 00 movl $0x0,-0x28(%rbp)
29: eb 10 jmp 3b <func+0x3b>
n[i] = b;
2b: 8b 45 d8 mov -0x28(%rbp),%eax
2e: 48 98 cltq
30: 8b 55 dc mov -0x24(%rbp),%edx
33: 89 54 85 e0 mov %edx,-0x20(%rbp,%rax,4)
for (int i = 0; i < 4; i++) {
37: 83 45 d8 01 addl $0x1,-0x28(%rbp)
3b: 83 7d d8 03 cmpl $0x3,-0x28(%rbp)
3f: 7e ea jle 2b <func+0x2b>
}
}
41: 90 nop
42: 48 8b 45 f8 mov -0x8(%rbp),%rax
46: 64 48 33 04 25 28 00 xor %fs:0x28,%rax
4d: 00 00
4f: 74 05 je 56 <func+0x56>
51: e8 00 00 00 00 callq 56 <func+0x56>
56: c9 leaveq
57: c3 retq
这是32位版本。
test_32.o: file format elf32-i386
Disassembly of section .text:
00000000 <func>:
void func() {
0: f3 0f 1e fb endbr32
4: 55 push %ebp
5: 89 e5 mov %esp,%ebp
7: 83 ec 28 sub $0x28,%esp
a: e8 fc ff ff ff call b <func+0xb>
f: 05 01 00 00 00 add $0x1,%eax
14: 65 a1 14 00 00 00 mov %gs:0x14,%eax
1a: 89 45 f4 mov %eax,-0xc(%ebp)
1d: 31 c0 xor %eax,%eax
int n[4];
int b = 11;
1f: c7 45 e0 0b 00 00 00 movl $0xb,-0x20(%ebp)
for (int i = 0; i < 4; i++) {
26: c7 45 dc 00 00 00 00 movl $0x0,-0x24(%ebp)
2d: eb 0e jmp 3d <func+0x3d>
n[i] = b;
2f: 8b 45 dc mov -0x24(%ebp),%eax
32: 8b 55 e0 mov -0x20(%ebp),%edx
35: 89 54 85 e4 mov %edx,-0x1c(%ebp,%eax,4)
for (int i = 0; i < 4; i++) {
39: 83 45 dc 01 addl $0x1,-0x24(%ebp)
3d: 83 7d dc 03 cmpl $0x3,-0x24(%ebp)
41: 7e ec jle 2f <func+0x2f>
}
}
43: 90 nop
44: 8b 45 f4 mov -0xc(%ebp),%eax
47: 65 33 05 14 00 00 00 xor %gs:0x14,%eax
4e: 74 05 je 55 <func+0x55>
50: e8 fc ff ff ff call 51 <func+0x51>
55: c9 leave
56: c3 ret
Disassembly of section .text.__x86.get_pc_thunk.ax:
00000000 <__x86.get_pc_thunk.ax>:
0: 8b 04 24 mov (%esp),%eax
3: c3 ret
你可以看到编译器分别生成了24个字节和20个字节，如果你在变量声明之后查看的话。
关于您要求的建议/提示，一个好的起点是启用所有编译器警告并将其视为错误。在GCC和Clang中，您将使用-Wall-Wextra-Werror-Wfatal errors。
不过，如果您使用的是MSVC编译器，我不建议这样做，因为它通常会对它分发的头文件中的声明发出警告。
-
问题内容： 我有用32位汇编语言编写的程序…现在，我无法在64位OS上对其进行编译。在我们学校，它们是特定的，程序必须以32位版本编写。这是我的程序： 任何的想法？我尝试了很多方法来编译它。编译后输出错误： 输出： 问题答案： 首先将更改为并将符号更改为，然后使用链接目标文件，该文件将自动链接至该文件， 您需要这样做，因为AFAIK如果没有，就无法链接至libc。另外，在汇编时也应使用elf32而
-
所有编程语言都被翻译成机器代码，然后由硬件解释器执行。但是什么翻译译码器的代码，例如编译器代码和解释器代码？编译器翻译源代码，但编译器也用某种语言编写，那么什么翻译编译器代码/代码呢？ 谢谢
-
问题内容： 在方法或类范围内，下面的行进行编译（带有警告）： 在类范围中， 变量获取其默认值 ，以下给出“未定义引用”错误： 它不是第一个应该以相同的“未定义参考”错误结束吗？还是第二行应该编译？还是我缺少什么？ 问题答案： tl; dr 对于 字段 ，是非法的，因为它是对的非法前向引用。您实际上可以通过编写来解决此问题，该文件可以毫无抱怨地进行编译。 对于 局部变量 ，是非法的，因为未在使用前进
-
本文向大家介绍详解Hadoop2.7.2 编译64位源码，包括了详解Hadoop2.7.2 编译64位源码的使用技巧和注意事项，需要的朋友参考一下 一、环境准备 1.CentOS配置 最好是用新克隆的虚拟机 ，虚拟机内存设置大一点（我设置的4G），配置网络，主机名，关闭防火墙，关闭selinux 注意：采用root角色编译，减少文件夹权限出现问题 2.jar包准备(hadoop源码、JDK8、ma
-
我经常遇到这种情况。乍一看，我认为，“这是糟糕的编码；我正在执行一个方法两次，必然会得到相同的结果。”但想到这里，我不得不怀疑编译器是否像我一样聪明，并能得出相同的结论。 编译器的行为是否取决于 方法的内容？假设它看起来像这样（有点类似于我现在的真实代码）： 除非对这些对象来自的任何存储进行处理不当的异步更改，否则如果连续运行两次，肯定会返回相同的内容。但是，如果它看起来像这样（为了论证而无意义的
-
问题内容： 我遇到了一个有趣的问题，我忘记了我正在使用64位计算机和操作系统，并编写了32位汇编代码。我不知道如何编写64位代码。 这是Linux上Gnu汇编程序（AT＆T语法）的x86 32位汇编代码。 现在，此代码应该可以在32位处理器和32位操作系统上正常运行，对吗？众所周知，64位处理器与32位处理器向后兼容。因此，这也不是问题。由于在64位OS和32位OS中系统调用和调用机制存在差异，因