c语言scanf越界问题

c语言scanf越界问题,第1张

你首先要明白,从键盘读入键盘缓冲区(buffer)的数据都是以ASCII码存储的(包括回车)。

程序1

#include "stdioh"

void main()

{

char a;

char b;

scanf("%d",&a);

scanf("%d",&b);

printf("%d %d",a,b);

}

键盘输入

97<回车>

第一次回车后,buffer中的ASCII:39h,37h,0AH(0A是换行的ASCII), scanf会根据格式字符串中的第一个%d对buffer按字节顺序读取,当读取到0A时,认为%d型的数据结束,此时把已经读取到的39h,37h依据%d转为整型数据97存储在字符型变量a中。(这里是除去了扫描截止点0AH)

此时buffer中已经无任何数据了。

96<回车>

第二次回车后,按同样的流程,scanf会根据格式字符串中的第二个%d对buffer按字节顺序读取。最终b得到96

此时buffer中已经无任何数据了。

输出

97 96

程序2

#include "stdioh"

void main()

{

char a;

char b;

scanf("%c",&a);

scanf("%c",&b);

printf("%d %d",a,b);

}

键盘输入

9<回车>buffer:39H,0AH

因为scanf会按照第一个%c格式扫描buffer(只扫描一个字节就结束),然后把扫描到的39H直接送到变量a(当以%d格式读出来时,39H就是57)

此时,buffer中只有:0AH。

然后,scanft又遇到第二个%c,继续扫描buffer,得到0aH并送入变量b

此时buffer中已经无任何数据了

输出

57 10

程序3

#include "stdioh"

void main()

{

char a[100];

char b[100];

scanf("%s",a);

scanf("%s",b);

printf("%s %s",a,b);

}

键盘输入

abc<回车>

第一次回车后,buffer:61H,62H,63H,0AH。

scanf会按照%s的格式对buffer按字节顺序扫描,当扫描到0AH时,结束扫描(按照%s的要求,空格20H也是扫描结束点)。

然后把扫描到的(除去最后一个判断扫描截至的字节0AH)数据直接送入以a为起始地址的字符串。

此时,buffer无任何数据了。

def<回车>

第二次回车后,buffer:65H,66H,67H,0AH扫描的流程与上面的完全一致。

输出

abc def

程序4

#include <stdioh>

void main()

{

int i;

char j;

for(i=0;i<2;i++)

scanf("%c",&j);/注意这里%前没有空格/

printf("%d",j);

}

键盘输入

1<回车>,

这里scanf执行了两次(i==0时,与i==1时),而且每次都是想对j赋值。

第一次scanf,按%c的要求,只扫描buffer中的一个字节,但是buffer中并不数据,于是要求键盘输入数据到buffer,此时的1<回车>代表向buffer中输入了:31H,0AH。

然后按%c的要求,只扫描buffer中的一个字节:31h,并将它直接送入变量j

此时,buffer中还留下:0AH。

第二次scanf要求键盘输入数据,按%c的要求,只扫描buffer中的一个字节:0Ah,并将它直接送入变量j

此时,buffer无数据了。

最后,你用%d格式输出j的值(0AH换成整型就是10)

输出

10

程序5

#include <stdioh>

void main()

{

int i;

char j;

for(i=0;i<2;i++)

scanf(" %c",&j);/注意这里%前有一个空格/

printf("%d",j);

}

1<回车>2<enter>的情况:

scanf会按照格式控制字符串的要求,顺序扫描buffer

但是你其中有一个空格,这个很特殊,我也是第一次发现这个问题(一般我都不会在scanf中加入任何常量字符)

我测试了一下:我发现这个空格有吸收回车(0AH)和空格(20H)的“神奇功效”,吸收之后再要求buffer给一个字节,直到这个字节不是0AH或者 20H,此时把这个字节交给下一个格式字串。

第一次循环时遇到格式字串空格,就扫描buffer中的一个字节,但是buffer中无数据,要求从键盘输入数据:1〈回车〉,buffer中有数据了——31H,0AH。再读取到字节31H,scanf发现这个并不是0AH/20H,就把这个字节31H交给格式字符%c处理。

循环结束,此时buffer里面还有:0AH

第二次循环时遇到格式字串空格,就扫描buffer中的一个字节——0AH,发现是0AH/20H,于是就要求buffer再来一个字节。此时buffer里面已经没有数据了,要求键盘输入:2<enter>

buffer中有数据了——32H,0AH。于是再读一个字节31H,scanf发现这个并不是0AH/20H,就把这个字节32H交给格式字符%c处理(j最终得到32H)。

循环结束,此时buffer里面还有:0AH

这里有一篇关于Printf的帖子:

程序6

#include "stdioh"

void main()

{

int a;

int b;

scanf("%c",&a);

scanf("%c",&b);

printf("%d %d",a,b);

}

键盘输入

1<回车>

问题5:

你的编译器VC认为%d数据应该是4个字节,但是你采用的是%c读数据,

scanf("%c",&a);此句读到的是1的ascii码:31h然后把31H直接送入地址&a(而并没有改写a的三个高字节地址)。

scanf("%c",&b);同理。

你可以用printf("a=%x,b=%x\n",a,b);来验证我说的。它们的最低字节肯定是31H,0AH。

PS1:

当你把 int a;int b;放在main()外进行定义时,a,b的初值就是0。此时你会得到正确的结果。

当你把 int a;int b;放在main()内进行定义时,a,b不会被初始化(它们的三个三个高字节地址的内容是不确定的),你就会得到上面错误的结果。(定义的动态变量都不会被初始化,静态变量会被初始化为0)

PS2:以下也是不正确的用法。

char c;

scanf("%d",&c);/当你用%d给c赋值时,会对从&c开始的连续4个字节进行赋值。当从buffer得到的值是在一个字节范围内(-128~127),下面是可以正常输出的。但是不管怎样,这样做是很危险的——越界。

printf("%d",c);

=================请你测试下这个程序========================

#include "stdioh"

void main()

{

char c[4],i=4;

scanf("%d",c);/请输入258<回车>/

while(i-->0)

printf("%02x ",c[i]);

printf("\n");

}/如果得到的结果是00 00 00 01 02就说明我的结论是正确的(258的转为16进制数就是00 00 01 02H,然后scanf会把这个数放入以c为起始地址的)

================以下程序也是======================

#include "stdioh"

void main()

{

char c,i=4;

char p=&c;

scanf("%d",&c);/请输入258<回车>/

while(i-->0)

printf("%02x ",p[i]);

printf("\n");

}

C++中,并不会自动检查下标越界问题。

第一个程序中,a[10]=a[9],改变了不属于数组空间的内存单元。这个错误不会在编译和连接中反应出来,而是会一直运行下去,知道出现结果不正确。严重时可能导致死机。

第二个程序也是同样道理,数组a只申请了三个整形的内存空间,越界的部分修改了内存中原来的数据。不过在这里编译会报错。

要保证不破坏其他存储空间中的数据只能说自己注意了。

因为,内存的分配是从高地址到低地址进行的,但一个数组内部元素又是从低到高进行的,所以:

语句序列

int i=0; int a[]={10,30};

的内存分配情况是(地址:低--高):

a[0] a[1] i

而语句序列

int a[]={10,30}; int i=0;

的内存分配情况是(地址:低--高):

i a[0] a[1]

所以,前者越界影响到了i,而后者越界没有影响到i。

对于数组而言,大部分语言中,数组的下标都是从0开始的,因此:

定义 int a[9]; 则,其最大下标为8(0,1,2, 3,4,5, 6,7,8)

所以,上面代码肯定会越界,因为 最大时,下标为9了

以上就是关于c语言scanf越界问题全部的内容,包括:c语言scanf越界问题、C语言数组下标越界问题、c语言数组越界等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!

欢迎分享,转载请注明来源:内存溢出

原文地址:https://54852.com/zz/10176562.html

(0)
打赏 微信扫一扫微信扫一扫 支付宝扫一扫支付宝扫一扫
上一篇 2023-05-06
下一篇2023-05-06

发表评论

登录后才能评论

评论列表(0条)

    保存