Intel® C++ Compiler
Support and discussions for creating C++ code that runs on platforms based on Intel® processors.
7690 Discussions

sscanf not working good in icl 12.0.5

Naveen_Tulabandula
218 Views
Below code is working good in 10.1.0.32 but failing to produce correct output
in 12.0.5
working env :: win2k8 R2 64-bti
#include
int main()
{
char buf[100]="ORACORE 4 6 0 1 2# none alpha";
char ver[100];
char prod[101];
int v1, v2, v3, v4, v5;
char vc=10;
char dist[102];
const char *distptr;
char reltype[5];
int rtype;
sscanf((const char *)buf, "%s%d%d%d%d%d%c%s%s", prod, &v1, &v2, &v3, &v4, &v5, &vc, dist, reltype);
printf("buf ::%s\\n",buf);
printf("sscanf ::*%s*\\n*%d*\\n*%d*\\n*%d*\\n*%d*\\n*%d*\\nvc::%d\\n*%s*\\n*%s*\\n",prod, v1, v2, v3, v4, v5, vc, dist, reltype);
}
0 Kudos
4 Replies
JenniferJ
Moderator
218 Views
thank you for letting us know and with a testcase.

I'll file the bug and get it fixed. It does not with 13.0 beta as well.

btw, the latest production compiler is 12.1 update 10. your version is a little old.

Jennifer
ILevi1
Valued Contributor I
218 Views
This is what I am getting:

T:\WORK>icl scan.cpp
Intel C++ Compiler XE for applications running on IA-32, Version 13.0.0.041 Beta Build 20120425
Copyright (C) 1985-2012 Intel Corporation. All rights reserved.

scan.cpp
Microsoft Incremental Linker Version 10.00.40219.01
Copyright (C) Microsoft Corporation. All rights reserved.

-out:scan.exe
scan.obj

T:\WORK>scan
buf ::
sscanf ::*ORACORE*
*4*
*6*
*0*
*1*
*2*
vc::35
*none*
*alpha*
JenniferJ
Moderator
218 Views
Our engineer found that the following var is too small. I should have read the code more carefully as well.
If you change the "5" to "6", it works great. It is an user error in this case.

char reltype[5];

Jennifer
Naveen_Tulabandula
218 Views
Thanks a lot.

I understood the mistake i did
As there is no space for NULL character it is placing NULL in next memory address which was already allocated to variable v1. Hence 4 is overwritten with 0.
I didn't know that all char arrays will be allocated memory consecutively on stack irrespective of the order in which they are declared in the program.
Thanks for looking into it.
Naveen
Reply