for loop problem driving me insane!!

[creeping death]

well,

it just does not make any sense...

here is my code

#include<stdio.h>

int plain[3],key[3][3],cip[3];

int conv_to_num(char p)
{
    int val=0;
    val=(int) p;
    printf("p=%c,val=%d\n",p,val);
    val=val-97;
    printf("val=%d\n",val);
    return val;
}

void enc()
{
    char key1[9],plain1[3],cip1[3];
    int temp[9],i=0,j=0,k=0;
    k=0;
    printf("Enter the key matrix in the form of a string==");
   gets(key1);
    printf("Enter the plain text matrix in the form of a string==");
    gets(plain1);
    for(i=0;i<9;i++)
    {
        printf("key[%d]=%c\n",i,key1[i]);
        temp[i]=conv_to_num(key1[i]);
        printf("i=%d,%d\n",i,temp[i]);
    }

     for(i=0;i<3;i++)
    {
        plain[i]=conv_to_num(plain1[i]);    
        printf("%d\n",plain[i]);    
    }
}

int main()
{
     enc();
     return 0;
}

this the output i get...

$ gcc ****edup.c 
/tmp/ccMKBfee.o: In function `enc':
****edup.c:(.text+0x87): warning: the `gets' function is dangerous and should not be used.
$ ./a.out
Enter the key matrix in the form of a string==asdfghjkl
Enter the plain text matrix in the form of a string==asd
key[0]=
p=,val=0
val=-97
i=0,-97 ****what the????****
key[1]=s
p=s,val=115
val=18
i=1,18
key[2]=d
p=d,val=100
val=3
i=2,3
key[3]=f
p=f,val=102
val=5
i=3,5
key[4]=g
p=g,val=103
val=6
i=4,6
key[5]=h
p=h,val=104
val=7
i=5,7
key[6]=j
p=j,val=106
val=9
i=6,9
key[7]=k
p=k,val=107
val=10
i=7,10
key[8]=l
p=l,val=108
val=11
i=8,11
p=a,val=97
val=0
0
p=s,val=115
val=18
18
p=d,val=100
val=3
3   ****Surprisingly this came out nicely*****

the problem is that the first character of the string key1 is not passed to the function "conv_to_num()", but characters of string plain1 get processed by the function correctly? how and why is this happening to me???


i m using gcc --version
gcc (GCC) 4.3.2 20081105 (Red Hat 4.3.2-7)

[TheCPUWizard]

Step through it with the debugger, and look at tthe variables that are being processed...


ps: What happens if you put 10 pounds of something in a 9 pound container.

The debugger will show you what your diagnostics do not....

[creeping death]

ps: What happens if you put 10 pounds of something in a 9 pound container.

consider this addition to the code in the "enc()" function.

printf("\n---------------------\nkey1[0] is %c\n---------------------------\n",key1[0]);

the output

]$ ./a.out
Enter the key matrix in the form of a string==asdfghjkl

---------------------
key1[0] is a
---------------------------
Enter the plain text matrix in the form of a string==

clearly key1[0],key1[1].....key1[9] are all stored and passed ....

and i dont know any debugger for gcc... i m totally new to gcc.
as you might have observed, i m compiling using the terminal emulator of linux(gnome) using the "gcc command" . would you kind enough to recommend me one?

[Paul McKenzie]

well,

it just does not make any sense...

Enter the key matrix in the form of a string==asdfghjkl
Enter the plain text matrix in the form of a string==asd

The arrays are too small. You are trying to stuff more than 9 characters (that's right, "asdfghjkl" contains more than 9 characters) into an array that can only hold 9 characters. The same thing with the 3 character input.

The C-style strings are always NULL terminated. So you have 10 characters when the NULL is included, not 9

Also, don't use gets(). From the Linux man pages:

Bugs

Never use gets(). Because it is impossible to tell without knowing the data in advance how many characters gets() will read, and because gets() will continue to store characters past the end of the buffer, it is extremely dangerous to use. It has been used to break computer security. Use fgets() instead.

Regards,

Paul McKenzie

[TheCPUWizard]

and i dont know any debugger for gcc... i m totally new to gcc.

GDB is the default debugger. And you should become 100% familiar with the debugger before writing ANYTHING more complicated than:

int f(int v)
{
   return v;
}
int main()
{
 int a = 1;
 int b = f(a);
}

Spend some time with this program until you are familiar with at least:
1) Setting a Breakpoint.
2) Stepping OVER a function.
3) Stepping Into a function.
4) Looking at the call stack.
5) Locking at local variable.

[creeping death]

ok

heres what gdb had to say....this is really pissing me off now...please help me before i throw my computer out the window....

$ gdb a.out
GNU gdb Fedora (6.8-29.fc10)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...
(no debugging symbols found)
(gdb) 
(gdb) a.out
Ambiguous command "a.out": .
(gdb) run
Starting program: /home/c_d/workspace/Info Security/a.out 
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
Enter the key matrix in the form of a string==asdfghjkl

---------------------
key1[0] is a
---------------------------
Enter the plain text matrix in the form of a string==asd
key[0]=
p=,val=0
val=-97
i=0,-97
key[1]=s
p=s,val=115
val=18
i=1,18
key[2]=d
p=d,val=100
val=3
i=2,3
key[3]=f
p=f,val=102
val=5
i=3,5
key[4]=g
p=g,val=103
val=6
i=4,6
key[5]=h
p=h,val=104
val=7
i=5,7
key[6]=j
p=j,val=106
val=9
i=6,9
key[7]=k
p=k,val=107
val=10
i=7,10
key[8]=l
p=l,val=108
val=11
i=8,11
p=a,val=97
val=0
0
p=s,val=115
val=18
18
p=d,val=100
val=3
3

Program exited normally.
Missing separate debuginfos, use: debuginfo-install glibc-2.9-3.i686
(gdb)

[creeping death]

The arrays are too small. You are trying to stuff more than 9 characters (that's right, "asdfghjkl" contains more than 9 characters) into an array that can only hold 9 characters. The same thing with the 3 character input.

The C-style strings are always NULL terminated. So you have 10 characters when the NULL is included, not 9

ok thats a mistake, but why should the first character be punished for my mistake??? i increased the size to 10 and 4 ... still no improvement

though there is no problem for the second string. the first string is causing all the problems.

[TheCPUWizard]

[The arrays are too small. You are trying to stuff more than 9 characters (that's right, "asdfghjkl" contains more than 9 characters) into an array that can only hold 9 characters. The same thing with the 3 character input.

EXACTLY whaty I said in my first reply.....

ps: What happens if you put 10 pounds of something in a 9 pound container.

ok thats a mistake, but why should the first character be punished for my mistake???

WHERE do you EXPECT the computer to STORE the tenth character????

The debugger would clearly show what was happening. Since you are not willing to spend a few hours/days learning how to use the single most important tool in programming, Iwill leave you to your own devices....

[Paul McKenzie]

ok thats a mistake, but why should the first character be punished for my mistake???

First, a memory overwrite isn't just a minor mistake. It is the cause for many security related issues. Read the link to gets() that I gave you. You are seeing exactly what a buffer overrun exploit can do, and that is mess up your data. What if a social security number or password info was stored at the addresses you are overwriting?

The term "memory overwrite" means just that. You are overwriting memory when you exceed the boundaries of an array. What memory you overwrite depends on how the compiler has set up your variables in memory. Since key1[9] is 1 byte above the valid key1[8], you are overwriting whatever variable is really located at key1[9] and without you knowing it, changing the value to NULL (that is, if you're lucky it's your other variables located at key1[9] -- if not, you would more than likely crash).

Also, debugging means stepping through the program a line at a time. You didn't do that -- you just ran the program at "full speed", which doesn't do you any good.

Regards,

Paul McKenzie

[Paul McKenzie]

EXACTLY whaty I said in my first reply.....

You're correct -- just wanted to explain what is happening with C-style strings and the input. I didn't feel that the OP "got it" on the first reply.

Regards,

Paul McKenzie

[TheCPUWizard]

You're correct -- just wanted to explain what is happening with C-style strings and the input. I didn't feel that the OP "got it" on the first reply.

Agreed, which is why I recommended (and was ignored) about using the debugger. As soon as that line was executed (while single stepping, and watching all of the variables) the write would have been obvious. [as you well know]

[creeping death]

well, read some stuff about gdm from here...http://sourceware.org/gdb/current/on...db_2.html#SEC5

and some other stuff from various other sites...learnt the importance of debugger....and sorted out the problem. everything seems to be working fine now...thanks for the help. and the valuable tips....appreciate the help.

PS-special thanks to Paul McKenzie for patiently explaining stuff to me...greatly appreciate it.

[Peter_APIIT]

I agree with two expert here.

Student often lack of skills to debug but they hope posting to forum and someone can help they do it.


Although i still a student but i have 1 and half years of C++/ 9 moths of C programming experience and you don't speed time(Interest) to learn.

Today, it is my first day of student J2EE training and it's like kindergarten programming where lecturer asked us to something and give us some guideline but when you go out your boss throw a bunch of task and you just do it with your thinking. Be prepare for real world.

Sorry if this hurt someone feeling or you feel like rude.

If you feel linux debugger is difficult, then switch to MS.

Thanks.

[kempofighter]

well, read some stuff about gdm from here...http://sourceware.org/gdb/current/on...db_2.html#SEC5

and some other stuff from various other sites...learnt the importance of debugger....and sorted out the problem. everything seems to be working fine now...thanks for the help. and the valuable tips....appreciate the help.

PS-special thanks to Paul McKenzie for patiently explaining stuff to me...greatly appreciate it.

Thanks for letting us know, however it would be nice if you could click the "thread tools" link and mark the thread resolved so that others don't scroll through the entire confusing thread before realizing that the problem is solved.

By the way, was the problem simply the array size? It'd be helpful to future readers if you clarify specifically what you did to solve the problem.

Best Regards,
Shawn